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An Electronic Check Presentment System provides a bank 
with a fully automated capability for participating in the elec- 
tronic exchange of check data. It allows banks that utilize the 
system to take MICR data that has been obtained through check 
capture methods (107), selectively extract particular check re- 
cords and place them in the form of electronic cash letters (105), 
transfer (115) the electronic cash letters to selected banks, re- 
ceive electronic cash letters from other banks, reconcile the elec- 
tronic cash letters (105) against the paper cash (113A, B) letters 
when they arrive, and input the electronic MICR data into a dat- 
abase (107) responsible for maintaining check records. 
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ELECTRONIC CHECK PRESENTMENT SYSTEM . 
A portion of the disclosure of this patent document contains material which is 
subject to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by any one of the patent disclosure, as it appears in the Patent and 
Trademark Office patent files or records, but otherwise reserves all copyrights 
5 whatsoever. 

Technical Field Of The Invention 

This invention relates to the field of electronic check processing, and more 
specifically, to a data processing methodology and apparatus that allows all banks that 

utilize th is invention to electronically transfer and receive check informa tion 

10 Background Of The Invention 

For some time, banking institutions have handled the presentment of checks for 
payment in a manual fashion. At a specified time each day, a bank sorts all checks 
presented to it into bundles, with the bundles pertaining to particular banks on which 
they are drawn (the "drawee bank"). As the checks are sorted for particular destination 
15 banks, they are gathered into batches of about 300 checks. One or more of these 
batches are then aggregated for shipment to the destination or "payor" bank. A cover 
letter is attached to each shipment of checks that summarizes the contents of the 
shipment. Such summary information comprises the name of the payor bank, a number 
associated with the name of the drawer bank (called the routing transit number), the 
20 number of checks in the shipment and the total dollar amount of all of the checks in 
the batch. The cover letter is termed a Cash Letter. The presenting bank then 
transfers to the payor bank the "Cash Letter", which includes the cover letter and the 
bundle of checks. 

When the drawee bank receives the Cash Letter, it verifies that the contents of 
25 the cash letter, i.e., the checks, agree with the totals contained on the cover letter. 
The bank also determines whether enough money exists in the payor customer's 
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account to cover payment of the check, and either accepts or rejects payment of the 
check. The payor bank then notifies the presenting bank regarding any balancing 
discrepancies or any items which are to be returned. 

The above procedure is an over-simplification of the process established for 
5 clearing checks between banks. However, it is sufficient to demonstrate the problems 
associated with such a process. A first problem resulting from the above process is the 
delay between the time a check is first deposited at the presenting bank and the time 
the drawee bank accepts or rejects the check. The payor bank has the choice of either 
placing a hold on the depositing customer's bank account until it is notified of 

10 acceptance by the payor bank, or it pays out the money to the presenter and incur the 
risk that the check will be rejected by the drawee bank. 

Many banks choose not to incur such a risk, and therefore place a hold on the 
presenter's bank account until it is notified that the check has been accepted. 
However, the time that it takes for the payor bank to be notified that a check has been 

45 — a<xepted-or-rejected-may~ — The-Expedited-Funds 

Availability Act of 1987, however, places limits on the length of time that a bank may 
retain a hold on a customer's funds. In most cases, only two days are allowed for local 
items, and only three days for non-local items. These time limits can severely expose 
a bank to risks of loss and fraud by forcing a bank accepting customers deposits to 

20 release funds to that customer prior to verification that those funds are, in fact, 
collectable from the payor institution. 

To overcome the problem of delay, banks have attempted to automate the 
process of gathering checks into cash letters, sending and receiving cash letters, and 
reconciling these cash letters against their contents. Such attempts at automation have 

25 included the installation of check sorter machines that scan checks at very high speeds, 
and sort these checks into bundles associated with payor banks. The sorter "reads" 
information contained on the checks such as the routing transit number, the drawer's 
account number, the check number and the amount of the check. This information is 
stored in a line of symbols at the bottom of each check in MICR (Magnetic Ink 

30 Character Recognition) form. Check sorter machines have been used quite successfully 
and are well known in the art. 
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Another attempt at automating the check process is the use of computer systems 
to record and manage the information associated with the check sorting procedure. 
Such computer systems interface with the check sorter machines and allow the 
computer systems to build database information associated with each check that is read. 
5 This allows an operator of a computer system to obtain information on checks that have 
been read such as the total number of checks drawn on specific banks and the total 
dollars of all checks drawn on specific banks. One such system that accomplishes this 
task is the IBM CPCS (Check Processing Control System). 

Although both of the above attempts have benefitted the banking industry, they 
10 have failed to address the problem of delay associated with the transfer of cash letters 
between banks. Better transportation, overnight express, and other services have 
helped to improve the transfer of cash letters, but the transfer of the information 
contained in the cash letters has still been dependent on the physical delivery of the 
cash letters to the drawee bank. Such dependence on the physical transfer of the cash 
15 letters perpetuates the delay associated with acceptance or rejection of particular 
checks: 

Another problem associated with the transfer of cash letters between banks is 
the inability of either bank to specify, for identification purposes, a particular check 
that was sorted by the other banks system. As each check is captured on the check 

20 sorting machines, a micro-film image is captured, and a unique "item sequence 
number" is assigned by the CPCS system. The system then maintains a database of 
item sequence numbers so that it can later identify and find individual checks within 
the numerous rolls of micro-film. However, since each bank assigns its own item 
sequence numbers, there is currently no way for one bank to cross reference its own 

25 item sequence number to that of another bank. 

Although means have come into existence that allow for wire transfer, or 
electronic transfer of funds from banks, see Deming, U.S. Patent No. 4,823,264 and 
Case, U.S. Patent No. 4,270,042, these systems have dealt with transfer of funds 
between a bank and an individual user. No system to date has allowed banking 

30 systems to dectronically transfer, and control the transfer of, the large volume of 
checks deposited in their institutions every day. 
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Summary of the Invention 

It is therefore an object of this invention to provide a way for banks to 
electronically transfer cash letters and improve the delay resulting from physical 
transfer. 

5 An additional objective of this invention is to provide banks with a method for 

minimizing its risk of exposure to check loss and check fraud due to the legal limits 
placed upon banks for placing a hold on the funds of their customers. 

Another object of this invention is to allow a bank that utilizes electronic check 
presentment to reconcile the received electronic cash letters against the physical paper 
10 cash letters when they arrive. 

A further object of this invention is to allow both the depositing bank and the 
paying bank to re-associate the item sequence numbers assigned by both banks, and by 
the electronic check presentment system, to allow for easy cross-referencing. 

An additional object of this invention is to provide for electronic check 
45 — presentaent~withoutchangmg-ft^ 
presentment. 

A further object of this invention is to utilize existing check databases and check 
sorting machines in the electronic check presentment process so as to minimize the 
impact on present check presentment procedures. 

20 The Electronic Check Presentment System provides a bank with a fully 

automated capability for participating in the electronic exchange of check data. It 
allows banks that utilize the system to take MICR data that has been obtained through 
check capture methods, selectively extract particular check records and place them in 
the form of electronic cash letters, transfer the electronic cash letters to selected banks 

25 via existing computer-to-computer data transfer technology, to receive electronic cash 
letters from other banks, reconcile the electronic cash letters against the paper cash 
letters when the physical paper items arrive, and input the electronic MICR data into 
a database responsible for maintaining check records. 

. The Electronic Check Presentment System uses electronics to move check 

30 information efficiently between presenting and paying banks, and improves the 
collection and return processes by the amount of time required for transportation of the 
checks between banks and by allowing banks to debit customer accounts from 

SUBSTITUTE SHEET 
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electronically received items. Depositing banks begin the funds collection process by 
transmitting MICR line information while continuing the presentment of the physical 
checks via ground and air transportation. Checks deposited on a Monday can be 
presented electronically to the paying bank anywhere in the country that same evening. 
5 Because electronic check presentment can be completed faster than physical check 
presentment, the check presentment process can be accelerated by at least one day. 

To this end, the applicant has initiated the formation of ECCHO (Electronic 
Check Clearing House Organization) as a cooperative venture to implement electronic 
check presentment. The organization has designed a standard ECCHO format that 

10 mirrors a paper cash letter with detail records (checks) and summary records (batches 
and cash letters). When the presenting bank produces a paper cash letter, it also 
creates an electronic cash letter from its existing check capture files to send to the 
paying banks. After the paying bank receives and captures the paper checks, it then 
reconciles the paper checks with the electronic items. 

IS Brief Description of the Drawings 

ITGURE~T~is a schematic representation of an electronic check presentment 

system. 

FIGURE 2 is a schematic representation of a send sub-system for the electronic 
check presentment system. 

20 FIGURE 3 is a schematic representation of an alternate embodiment of the send 

sub-system. 

FIGURE 4A is a schematic block representation of a preprocessor for operation 
in a receive subsystem of the electronic check presentment system. 

FIGURE 4B is a schematic block representation of paper-less MICR capture 
25 operation in the receive sub-system; the paper-less MICR capture process will allow 
the CPCS to process electronically received items as if they were physical paper. 

FIGURE 4C is a schematic block representation of ECP strip file warehouse 
process in a receive sub-system. 

FIGURE 5 is a schematic block representation of a first paper sorting in the 
30 receive sub-system. 

FIGURE 6 is a schematic block representation of an ECP reconcilement 
process within the electronic check presentment system. 
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FIGURE 7 is a block schematic representation of a second paper pass directed 
fine sort operation of the receive sub-system. 

FIGURE 8 is a block schematic representation of an end-of-day settlement 
function in the receive subsystem. 
5 FIGURE 9 is a block schematic representation of a third paper pass directed 

fine sort operation of the receive sub-system. 
Detailed Description Of The Drawings 

Referring to FIGURE 1, partner banks 101 are members of an electronic 
check clearing house organization (ECCHO) 103. There is no limit on the number 
10 of banks that may participate in the ECCHO. Typically, each partner bank in the 
ECCHO has a check capture system 107, such as the industry standard Check 
Processing Control System (CPCS) of International Business Machines Corporation, 
and a demand deposit accounting (DDA) system 109. Both are data processing systems 
having various configurations well known in the art. Additionally, when participating 

-IS — m-theECCHO,-each-bankha^^ 

is coupled to the CPCS. The ECP system may run on the same data processing 
equipment or computer system as the CPCS or DDA. The CPCS, DDA and ECP 
systems are used as follows in an electronic presentment system. 

Partner banks 10 1A and 101B receive paper checks 111, usually deposited by 

20 their respective customers. After their deposit, the checks are "captured" by the 
CPCS, usually after the close of business on the day they are received. The capture 
process begins by passing the checks through check sorting machines (not shown). The 
sorters read characters on each paper check that are printed with magnetic ink and are 
provided to a magnetic ink character recognition (MICR) system for conversion to data 

25 that is stored in a CPCS mass data storage file, or MDS (not shown). The printed 
characters are sometimes collectively referred to as the MICR line, and the complete 
set of MICR-line data is sometimes called a check "image", as it contains most of the 
pertinent data on the check. The records in the CPCS MDS include fields for the 
routing/transit code for the payor bank (the bank on which the check is drawn), the 

30 account number of the customer who wrote the check, the serial number of the check 
and its amount. Based on the routing/transit number on the check, the CPCS directs 
the sorter to pocket the check for the bank on which it is drawn. 
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At various times throughout each business day, the CPCS generates a cash letter 
for each bank for which there are checks. The checks that are pocketed for each bank 
are then bundled with the respective cash letter. Collectively the checks and the letter 
are simply referred to as a cash letter 113. Assuming both banks 101A and 101B have 
5 checks drawn on the other bank, banks 101A and 101B deliver cash letters 113A and 
113B, respectively, to the other bank via a courier 114 service that physically 
transports the bundle to the respective bank. 

Once the cash letter has been produced, the ECP system at each bank prepares, 
using the same MICR-line data stored in the CPCS MDS data file, electronic cash 

10 letters for each "paper" cash letter 113A and 113B that is sent. This electronic cash 
letter is then sent to the respective banks, using standard communication techniques 
over one or more electronic or optical data transmission networks 115. 

Once received, the electronic cash letters are processed the same day by the 
receiving bank's ECP system 105 and CPCS 107. Generally, this involves having the 

15 ?5* systems first perform certain preprocessing functions, then presentin g this 
electronic caslfletter containing the MICR information to the CPCS. The CPCS then 
"captures" the items or checks in the electronic cash letter as if they were physical 
paper items, and sends some or all of these items to the bank's posting systems, such 
as Demand Deposits (DDA), and etc. This called a "non-MICR" capture, as the 

20 information is not being read by the CPCS from the magnetic ink characters on the 
paper checks, but from a "non-MICR" file created by the ECP. 

The couriers 114 usually deliver the paper cash letters 113A and 113B to the 
banks the next business day. Upon arrival, the paper checks are placed in the CPCS 
sorters at the receiving banks for capture by the CPCS system 107. After capture, the 

25 ECP system reconciles the electronic and the paper cash letters with the MICR line 
data. The checks are then handled in the usual manner by the banks. 

The forgoing is a general description of the functioning of a basic ECCHO 
exchange. Figures 2-8 illustrate details of the ECP system. Basically, it has two 
major sub-systems: 1) the Send System; and 2) the Receive System. An additional but 

30 critical component of the ECP system is an on-line CCF system, that is common to both 
the Send and the Receive subsystems, and will be first discussed without reference to 
a figure. In the preferred embodiment, the ECP is implemented with a general purpose 
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digital computer whose operation is directed by a program such as the one disclosed 
in the microfiche appendix submitted herewith. 

The On-line CIF System 
The On-line CIF System handles, among other things, on-line maintenance of 
5 partner bank records, benefit sharing percentages, and edit rules. It also provides a 
complete data base file list and audit control reporting. 

The majority of all benefits derived from the ECP process accrue to the bank 
receiving the electronic Cash Letter. ECCHO Rules permit each Receiving bank to 
negotiate benefit sharing arrangements independently with each prospective exchange 
10 partner, to provide an incentive to the partner for sending electronic Cash Letters to 
that bank. A key element of the system, then, is the centralized storage of each of these 
agreements within a single data base file. 

Additional data stored in the CIF system include fields of a general nature that 
identify the name of the partner banks, the primary contacts at the partner banks (for 
-15 — bom-sendtogand-recrivmgdata)and^ 

Data fields that are more specific are defined to include identification numbers for the 
partner banks, such as routing/transit numbers, version numbers of the ECCHO record 
formats to be sent to and received from the partner banks, send and receive cut-off 
times that define the target deadlines for the partner banks, send and receive volume 
20 cut-offs that identify the maximum number of items allowed for each banks 
transmission, and send and receive cash letter maximums that define the maximum 
number of cash letters allowed for transmission to and receipt from each partner bank. 

The CIF system also includes fields that pertain to profit/benefit sharing for 
each of the partner banks. These fields store the benefit percentages to be applied to 
25 the electronic cash letters that are sent to or received from the partner banks for each 
day of the week. Finally, the CIF system includes fields that are used to maintain 
information relating to the partner bank's records such as the date and time associated 
with the last update of the records, as well as identification of the user responsible for 
the last update. 

30 The maintenance portion of the CIF System comprises modules for adding, 

updating and deleting partner bank CIF records. The Add function allows an 
authorized user to input all partner bank data as detailed in the section discussed above. 
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The system contains logical edits that prevent a user from entering duplicate records 
(based on record type and bank-id fields). In addition, the system will not allow for 
sending data to, or receiving data from, partners with whom such exchanges have not 
been authorized in the CDF. This is determined by the ECCHO record version number. 
5 To ease the entry of information into the Add screen, the CIF System automatically 
inserts the current date, time and operator id into each new record. 

The Edit/Update portion of the CIF System prompts the user to enter the bank 
identification number for the requested record. The system then displays an edit 
screen, similar to the Add screen, that contains the data for the requested bank. The 
10 system allows an authorized user to modify all fields within the screen except the 
record type, bank-id and last update fields. In addition, the Edit/Update portion of 
the CIF System provides the same logical edits and automatic entries that are available 
in the Add portion. 

The Delete/Undelete portion of the CIF System allows an authorized user to 
15 mark a bank record as deleted as of a speci fied date. The D el ete/Undelete portion 
prompts the user to enter the bank-id number for the requested record. It then displays 
a screen, similar to the Add screen, containing information for the particular bank 
requested. The Delete/Undelete portion allows the user to close the account by 
entering an account closed date into the system. If, at a later time, the user wishes 
20 to re-open an account, he can do so by entering zeroes in the account closed date field. 

The CIF System also includes audit reporting features that detail the changes 
made to the CIF database, whether through Adds, Edits or Deletes. The System 
prompts the user to enter the start date for the report, with the end date of the report 
being the current system date. The CIF system scans the CIF database and selects only 
25 those records that fall within the date range specified by the user. The system then 
formats and prints a list of all data fields along with the corresponding changes to the 
data fields. In addition to these features, the CIF System includes the ability to print 
out a detail listing of all partner bank records currently on the CIF database. 

The Send System 

30 Referring now briefly to FIGURES 2 and 3, the Send portion of the Electronic 

Check Presentment System automatically handles the selection and extraction of 
targeted cash letters from the CPCS system. The Send portion may be divided into 
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two different segments that address the diverse requirements of the marketplace: a 
Basic Send segment, which is Cycle and String based, shown in Figure 2; and an 
Enhanced Send segment, which is Cash Letter and Kill Bundle-based, shown in Figure 
3. 

5 Referring now to just FIGURE 2, the Basic Send segment provides on-line 

capability for initiating the creation, or re-creation, of an electronic cash letter file. 
The cash letter file is, in essence, a sequential file suitable for transmission to partner 
banks. The Basic Send segment includes an extract module 201. The cash letter 
extract module 201 segment allows the user to select a specific destination bank, called 

10 an end point, extract all items associated with this end point, and create an electronic 
file of this data for conversion into a standard format. The user is first prompted to 
enter the specific cycle to be extracted from all cycles in the CPCS Mass Data Set 203. 
The extract module utilizes the bank records, discussed in the CD? System above, to 
dynamically build and display a screen containing all the bank names on file. The user 

15 can-then-select a-particular-bank-or-end-riomtfor^ 

module then extracts all item records from the CPCS Mass Data Set that correspond 
to the selected end point and cycle requested. Upon extraction, the module builds an 
intermediate extract file 209 that will be used by the ECCHO format module 211. 
After building the intermediate file, the extract module 201 formats and prints a paper 

20 detail report of all extracted items, and writes a summary record to an extract control 
file 207 containing the extracted end point and summary totals at the bundle level of 
all cash letters extracted for electronic transmission. The extract control file provides 
data for end of the day reporting, including an expected benefits report. 

The ECCHO formatting module 21 1 is automatically started from the cash letter 

25 extract module after the extract module builds the intermediate file. The module looks 
at the bank records in the CIF System to determine the proper ECCHO record version 
number currently in use by the specific end point bank for which the extraction was 
done. It then builds an electronic cash letter file, termed an ECCHO transmit file 
213. 

30 The electronic cash letter file in ECCHO format comprises check detail records, 

file, cash letter and batch headers, and file, cash letter and batch trailers. The check 
detail records include fields for the paying banks routing transit number, the payor's 



WO 93/02424 Best Available Copy 

-11- 



PCT/US92/05780 



account number, the amount of the check, the item sequence number assigned by the 
sending bank, and status fields that determine whether the sending bank anticipates 
benefit sharing, and whether the check being transmitted is for collection, return or 
return notice. The check detail record also includes fields for storing the depositor's 
5 account number, the originating banks routing transit number, the date and time the 
cash letter was created, and the cash letter number. 

A file header exists for each electronic cash letter file. The file header includes 
the ECCHO format version number for the receiving bank, the routing transit number 
of the presenting bank, the date and time the file was created, and the name of the 
10 presenting bank. A file trailer also exists for each electronic cash letter file. This 
trailer includes the total dollar amount of all check records in the file, the total number 
of cash letters in the file, and the total dollar amount of all benefit sharing records in 
the file. 

The electronic cash letter file also contains a cash letter header for each cash 
15 letter extracted. This header includes the routing transit numbers of both the origination 
bankmd~the~de$tinatioir 

the electronic cash letter file was created, the cash letter number, and the name of the 
originating bank. A cash letter trailer also exists for each cash letter in the file. This 
trailer includes some of the information contained in the cash letter header, as well as 

20 the total dollar amount of the cash letter. 

A third header in the electronic cash letter is the batch header. A batch header 
exists for each batch that was extracted from the CPCS Mass Data Set. The batch 
header includes the routing transit numbers of both the origination and destination 
banks, the date the batch was processed, the bundle ID, the bundle number, and the 

25 cycle number. A batch trailer record is also created for each batch extracted in the 
electronic cash letter. The batch trailer includes the total number of all check records 
in the batch, the total dollar amount of all check records in the batch, and the total 
dollar amount of all benefit sharing check records in the batch. 

In addition to the cash letter extract module, the Basic send segment of the Send 

30 System also includes an extract re-run module (not shown). This module allows the 
user to re-create a file that has been previously extracted. Upon completing the 
extraction, this module compares the results of the extraction with those of the previous 
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extraction. If the module detects a change in the information obtained through the 
extraction, it will notify the user that a particular data file, or string, is missing and 
will identify the missing string name, bundle number, bundle amount and item count. 

The Basic send segment also contains an extract re-start module that allows the 
5 user to re-start an extract job that failed due to a program or system problem. Upon 
execution by the user, the module creates a completely new extract file for the 
requested end point. 

In addition to the above modules, the Basic send segment includes a number of 
utilities that enhance the Send System. One of the utilities, end of day reporting 
10 module 215, allows the user to request the printing of a summary level report of all 
electronic cash letters sent out for a specific day, along with a the corresponding 
expected benefits report 217. A second utility allows the user to delete an entire entry 
from a previous extract file. 

Referring now to FIGURE 3, the Enhanced Send segment of the Send portion 
-lg_of_th& Electronic Check Presentment System exteids the functionalify^of the Basic Send - 
segment to include the capability of extracting at the cash letter bundle level and 
ensures that the paper cash Letter and the electronic cash letter are exact duplications 
of one another. The enhanced send segment includes modules and files that are 
functionally similar to those of the basic send system: CIF file 205; CPCS Mass Data 
20 Set file 203; extract control file 207; intermediate extract file 209; ECCHO formatter 
211; and ECCHO transmit file 213. 

An enhanced cash letter extract module 301 allows a user to select a specific 
bank and a specific cash letter time, and extract all killed items for this cash letter. 
The extract module functions similarly to the one in the basic send segment except that, 
25 after the user has selected a bank to be extracted, the user is prompted to enter the cash 
letter time which will identify the kill bundles to be extracted. The module will then 
read the CPCS kill bundle file 303 to select records which match the requested cash 
letter time. The selected records provide pointers into the CPCS Mass Data Set 
Strings, which are used to extract all item records for the corresponding kill bundle. 
30 The module then creates an intermediate extract file 209, which is processed through 
the ECCHO formatter 211 module as in the basic send segment. 
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The enhanced send segment includes a utility that allows the user to generate 
an end of day benefits summary report which is a summary level report of all 
electronic cash letters sent out for a specific day along with the corresponding expected 
benefit amounts. This utility prompts the user to enter the requested cycle for the 
5 report then extracts the data for the requested cycle and formats the information for 
printing. 

The Receive System 
Referring briefly to FIGURES 4A-8, a Receive System verifies, processes, and 
monitors the receipt of electronic cash letters from partner banks. It handles the 

10 automated entry of non-MICR data into CPCS and the follow-up reconciliation of the 
electronically captured items to the actual physical paper items. The Receive System 
comprises five modules: an input file preprocessor; a CPCS non-MICR input 
processing module; a reconciliation module, an image match/directed fine sort module; 
and an end of day reporting module. 

15 Referring now to FIGURE 4A, the input pre-processor module is a batch 

process ffiattseither manually^tarted, or auto-started~firom the transmission receive 
job. Its function is to balance and pre-edit an incoming ECCHO transmit or electronic 
cash letter file 213 from other partner banks. 

The pre-processor module 401 reads the presenting banks routing transit number 

20 contained in the file header record of the electronic cash letter file and validates this 
number against the routing transit numbers contained in the receiving banks GIF file 
205. The validation determines whether the sending bank is a valid sending partner, 
and whether a send agreement between the two is currently in force. If the sending 
bank is validated in both of these respects, the pre-processor continues to process the 

25 electronic cash letter file. 

Upon receipt and validation of each electronic cash letter file, a record for each 
file is created in a receive control file 403. The record comprises data associated with 
the electronic cash letter file such as the name of the file, the date and time the file was 
created, the total number of entries in the file, and other information pertaining to file, 

30 bundle and cash letter totals. This information is updated as pre-processing of the 
electronic cash letter file continues. 
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The electronic cash letter file is then checked for duplicates, at the file level, 
the cash letter level, and the bundle level by searching the records in the receive 
control file for matching creation dates and times, matching cash letter numbers and 
matching kill bundle identification codes and kill bundle numbers. If any duplicate 
5 cash letters exist, they are bypassed during processing. 

After checking for duplication, the pre-processor 401 balances the electronic 
cash letter file at the bundle level, the cash letter level and the file level. For 
balancing at the bundle level, the total number of all check records in the batch are 
balanced against the check record count extracted from the batch trailer. The total 
10 dollar amounts of all check records and all benefit sharing check records in the batch 
are also balanced against the check record count extracted from the batch trailer. 

The file is balanced at the cash letter level by comparing the total number of 
batch check records, the total dollar amount of all check records, and the total dollar 
amount of all benefit sharing records, that are extracted from the cash letter trailer with 
- 45- --fopse amounts calcuhtedby^ 
images. 

The pre-processor balances the electronic cash letter file at the file level by 
comparing the total dollar amount of all cash letters and the total number of cash letters 
in the file with the associated information contained in the file trailer. The 
20 pre-processor then prints a balancing report that lists, by cash letter, all out of balance 
batches, cash letters and/or files. 

The pre-processor will then reformat the incoming file into a CPCS MICR 
format file termed a "MICR" file 405 to differentiate from a MICR file that is created 
from capturing of paper checks. This non-MICR file includes fields that specify cycle 
25 codes, post/no-post codes and pocket codes. It then prints a block building report that 
assists the data prep/block building clerk in assembling the physical paper batches in 
the proper order for subsequent capture of the paper items. 

Referring now to FIGURE 4, after pre-processing, the non-MICR input file 405 
provided to the CPCS for a process termed paper-less MICR capture. To perform this 
30 process, a preexisting CPCS system is modified so that it is "tricked" into thinking 
that the items presented by electronic cash letter are paper items. The CPCS captures 
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and processes electronic cash letters as if they were normal paper cash letters, and all 
captured electronic items are assigned a second item sequence number by the CPCS. 

Illustrated are standard CPCS modules 407, each of which having processes 
well known in the art. Very briefly, the DKNMICR modules 409 includes all of the 
5 modules for interfacing with sorters for MICR capture and sorting. The OLRR SCI 
module 411 "edits" or checks the MICR line data for each item provided by the 
DKNMICR modules for validity (e.g. the routing/transit number and account number). 
Module 413 formats the MICR data for the item and assigns the item a pocket code for 
DDA or other posting system processing. This MICR data and the pocket code are 

10 written to an "all-items" I-String Information file 417, which is a mass data storage 
(MDS) file, in step 415. At merge step 419, the I-String Information file is 
converted to an M-String data file 421, by, in essence, stripping all control documents 
from the file. The CPCS extract module 423 then extracts the data necessary for 
posting to DDA or other posting systems. 

15 For working with the ECP system, only the DKNMICR module 409 of the 

GPGS-is-substantially-modified— C«e-modificatioTrallows a Statio7rConeol"BIock"to" 

be defined for an electronic cash letter sorter. The function indicates that an electronic 
cash letter sorter has been defined so that the CPCS system can generate the necessary 
control blocks for the electronic cash letter. Another modification adds references to 

20 the electronic cash letter extensions for the station control block and the MICR control 
table. The CPCS program is also modified to look for a run started on an electronic 
cash letter sorter. Upon detection, it passes control to the new electronic cash letter 
initialization module that loads the OLRR edits and retrieves a tracer number from the 
receive control file 417. When the electronic cash letter sorter run has been initialized, 

25 MICR task processing continues as if processing a normal paper run. 

Receive control file 417 is updated with balance summaries of the items 
processed from the electronic cash letter during the run by the DKNMICR modules 409 
for cash letter balance control. 

Upon completion of the non-MICR processing run, an ECP strip file 425 is 

30 created by an ECP strip file processing module 427. This module creates a flat file of 
the non-MICR input items in I-string sequence and DIIMAGE format. The strip file 
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creation module also creates a balance summary of the items entered in the ECP strip 
file 425 for error checking against the summary in receive control file 417. 

Referring now to FIGURE 4C, on the next day (day 2), the ECP strip file must 
be updated with information about whether there were items excepted in the DDA the 
5 night before and not posted, as well as the proper cycle information for each item that 
was posted. To create an updated ECP strip file 429, a pocket update module 431 in 
the ECP system matches each item in the ECP strip file 425 with corresponding DDA 
cycle for the item in DDA cycle file 433 and with any exceptions for the item in DDA 
exceptions file 435. 

10 Referring now to FIGURE 5, after the paper cash letter is received, it is sorted 

in a conventional manner, without modification, by the CPCS of the partner bank in 
what is termed the first paper sort. Paper items 501, the checks, are unbundled and 
fed throughout the MICR capture and sort system 503. The capture of the paper cash 
letter produces a an MDS I-String file 505, which is then merged at step 507 into an 

15 MDS~M^string.fi le509-that-will-be-used-as-an input intoareconciliation-sort module. 

Captured items 511 are gathered, as they will be used in a second paper pass (see 
Figure 7). Items rejected 513 is the MICR capture are reentered manually into the 
I-String file 505. All captured paper items are assigned a third item sequence number 
by the CPCS. 

20 Referring now to FIGURE 6, after the first paper pass, the paper items are 

reconciled with the electronic items received the previous day by electronically 
matching the two data files in the sort/match module 601. The sort/match module sorts 
through the ECP strip file 429 in order to match ECP strip file with the MDS M-String 
file 509 and merge the pocket codes from the strip file into the M-string file to produce 

25 a MDS D-String file 605. It then produces a full report 602 in account number and 
item sequence number sequence, and additionally produces a missing item/free item 
report 603. A missing/ftee report 603 details any missing paper items for which there 
was an electronic item, and any extra paper items for which there is not a 
corresponding electronic item. 

30 Referring now to FIGURE 7, the paper items 501 are once again passed 

through the CPCS system for pocketing the paper items. A directed fine sort module 
701 matches the image of the electronic item in the D-String file 605 with the actual 
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paper item as it is re-read by the electronic sorter, and directs the paper item to the 
appropriate pocket as dictated by the pocket code in the D-String file 605, and is 
further described below. The directed fine sort module assumes that a pocket code is 
present for each item in the electronic cash letter D-string. Thus, only paper items for 
5 which the corresponding electronic cash letter images have completed DDA processing 
are able to be directed to a pocket by the directed fine sort; all other unmatched items 
are considered free, or extra items and are directed to an unmatched pocket. 
Additionally, to facilitate matching of the paper items to the electronic items, the D- 
String file 605 is utilized, since these records are in the same physical sequence as the 

10 actual paper items from the first paper pass. 

The updated D-string file (containing the new pocket codes) directs the fine sort 
module, which in turn directs the sorter (not shown), to place matched paper items 703 
to a pocket. The matched posted items are pocketed by statement cycle, the matched 
exception items are pocketed by exception code, the physical rejected items are sent 

15 to a reject pocket, and the unmatched (free) items are sent to an unmatched pocket. 

AU~r€gected-items-705~are-fM^ 

remain. These items are then batched and re-captured on the electronic sorter along 
with all of the bank's other first time capture work. The matched items are 
transferred to bulk file vaults or exception processing as appropriate. 

20 The directed fine sort module expects that the D-String file 605 be in the same 

physical sequence as the paper items after the first paper pass. If the paper items are 
accidentty dropped, or otherwise become out of sequence between the first and the 
directed fine sort/second paper pass, an optional third paper pass is then provided to 
read the paper items in their current order, to re-order the D-String file 605 to match 

25 the new paper sequence, and then perform the directed fine sort. 

Referring now to FIGURE 8, an end-of-day settlement module 801 reads the 
ECP receive control file 417 and produces an end of day or week or month settlement 
report 803 by bank, for all electronic cash letters received and processed through the 
electronic check presentment system. Additionally, an item sequence cross reference 

30 report is produced, listing the three item sequence numbers associated with each item: 
the Sending Bank ISN, the Electronic ISN, and the paper ISN. Optionally, an item 
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sequence cross reference file can also be produced, for interface to various other look- 
up and retrieval systems. 

The above described system has shown to provide an improved electronic check 
presentment system that allows all banks that utilize this system to electronically 
5 transfer and receive check information, reconcile this information against actual paper 
check processes, and manage information associated with electronic check presentment 
such as cash letter, bundle and file totals, unmatched records/paper and benefit sharing 
amounts. 

The above described arrangement is merely illustrative of the principles of the 
10 present invention. Numerous modifications and adaptations thereof will be readily 
apparent to those skilled in the art without departing from the spirit and scope of the 
present invention as set forth in the appended claims. 
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What is claimed is: 

1. A check presentment system for use by a bank within an organization of 
banks to improve clearing of checks presented between partner banks within the 
organization, the system comprising: 

means for capturing check information from paper checks collected by a 
5 presenting bank and storing the information in a first data base; 

customer information file means for maintaining records identifying partner 
banks participating in an electronic check clearing organization and parameters relating 
to electronic check clearing; 

data processing means responsive to the customer information file means, the 
10 data processing means extracting from the first data base check information for check 
items to be presented to a selected partner bank and forming an electronic cash letter 
data file means, including check information and summary balances; 

electronic means for transmitting the electronic cash letter to a partner bank for 
presentment of check items by means of the check information in the electronic cash 
-15 — letter: : — • — ~'. " " ; — — — 

2. The check presentment system of Claim 1 further comprising: 
electronic means for receiving an electronic cash letter transmitted from a 

partner bank; 

data preprocessing means responsive to the customer information file means for 
5 validating the partner bank, the data preprocessing means further balancing the 
electronic cash letter and formatting the electronic cash letter for providing check 
information to the means for capturing check information; and 

data processing means for reconciling check information received from the 
partner bank in the electronic cash letter against check information received in a paper 
10 cash letter sent by the partner bank that corresponds to the electronic cash letter. 

3. The check presentment system of Claim 2 further comprising data 
processing means for controlling and maintaining records related to the transfer and 
receipt of the electronic cash letters. 
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4. The check presentment system of Claim 1 wherein the data processing 
means generates expected benefit reporting. 

5. A check presentment system for use by a bank within an organization 
of banks to improve clearing of checks presented between partner banks within the 
organization while utilizing preexisting check processing systems, the system 
comprising: 

5 a check processing and capture system (CPCS), the CPCS including: 

means for magnetic ink character recognition (MICR) for capturing 
check information from paper checks deposited by customers and received from 
a partner bank; 

data processing means for processing check information, the CPCS 
10 being modified to receive electronic check information; and 

mass data storage file means in which the captured check information 
-is stored;- 

data processing means for electronic check presentment, the data processing 
means including: 

file means for maintaining records on partner banks, the records 
including data identifying partner banks and parameters for electronic check 
presentment; 

send module means for extracting from the CPCS mass data storage file 
check information for transmission to a partner bank using identifying 
parameters from the file means, the send module formatting extracted check 
information according to a predefined format to form an electronic cash letter; 
and 

receive module means for preprocessing an electronic cash letter 
received from a presenting bank in order to provide for validation and balancing 
of the electronic cash letter, the receive module means providing the check 
information in the electronic cash letter to the CPCS for processing; and 
electronic communication means, coupled to the data processing means, for 
sending to and receiving from partner banks electronic cash letters. 



15 
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6. The check presentment system of Claim 5 wherein the send module 
means further provides for generating expected benefits report. 

7. The check presentment system of Claim 5 wherein the receive module 
means further reconciles an electronic cash letter received from a presenting bank with 
a corresponding paper cash letter received from the presenting bank. 

8. The check presentment system of Claim 5 wherein the receive module 
means further generates an item sequence number cross reference file for cross 
referencing a first item sequence number assigned to each electronic check item when 
an electronic cash letter is captured by the CPCS with a second item sequence number 

5 assigned to a corresponding paper check item during subsequent capturing of the paper 
cash letter. 



WO 93/02424 



PCT/US92/05780 



-22- 

9. An electronic check presentment system for managing, sending and 
receiving check information in the form of cash letters to and from banking systems, 
the system comprising: 

means for selecting check information for extraction from a designated database 
5 containing said check information wherein the selection criteria comprises a specific 
bank or end point and a cash letter time; 

means responsive to said selecting means for extracting said selected check 
information in the form of electronic cash letters; 

means for transmitting and receiving said electronic cash letters to and from 
10 other computer databases handling such check information; 

means for reconciling the transmitted electronic cash letters against captured 
paper cash letters, wherein the reconciliation is accomplished by comparing the 
electronic cash letters against captured paper cash letters to determine discrepancies, 
and reporting any discrepancies to the electronic check presentment system; and 
15 meM^orjcc^^ 

of said electronic cash letters, such information comprising the names, addresses, 
phone numbers and routing transit numbers of the banks utilizing the electronic check 
presentment system, information relating to benefit percentages that are to be shared 
by said utilizing banks, and dates and times related to specific transfers of electronic 
20 cash letters. 

10. The electronic check presentment system of Claim 9 further comprising: 
means for reporting summary information related to the transfer of electronic 

cash letters, such information comprising the number of checks contained in specific 
bundles, the total dollar amounts associated with specific cash letters and bundles, the 
5 total dollar amounts associated with the transfer of electronic cash letters to and from 
specific end points, and the dates and times associated with the transfers of specific 
electronic cash letters. 

11. A method for managing, sending and receiving check information in the 
form of electronic cash letters to and from banking systems, the method comprising 
the steps of: 
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capturing paper cash letters in electronic cash letter form and storing them in 
a computer database; 

selecting specific banks or endpoints that are to receive electronic cash letters; 
extracting from said database those cash letters associated with said selected 

5 banks; 

transmitting to said selected banks the extracted cash letters; 
receiving electronic cash letters from transmitting banks and storing them in a 
computer database; and 

reconciling said electronic cash letters against captured paper cash letters. 

12. The method for managing, sending and receiving check information in the 
form of electronic cash letters of Claim 11 wherein the selected banks or endpoints are 
provided by an on-line computer database that provides information on banks utilizing 
this method such as the names, addresses, phone numbers, routing transit numbers and 
5 contacts associated with selected banks. 



13. The method for managing, sending and receiving check information in the 
form of electronic cash letters of Claim 11 including the additional step of reformatting 
the extracted cash letters into a standard format prior to transmission to the selected 
banks. 

14. The method for managing, sending and receiving check information in the 
form of electronic cash letters of Claim 11 wherein the step of reconciling the 
electronic cash letters against captured paper cash letters is accomplished by comparing 
the electronic cash letters against captured paper cash letters to determine 

5 discrepancies, and reporting said discrepancies to a computer system responsible for 
said reconciliation. 
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15. A method for use by a bank in a organization of banks to reduce the time 
for payment on checks collected by it and presented to a bank within the organization 
for payment, the method comprising the steps of: 

maintaining an information file for partner banks in an organization of banks; 
5 capturing check information from paper checks collected at the bank and storing 

the check information in a first data base as check records; 

selecting an end point bank from the information file; 

extracting from the first data base check records for the selected bank; 

formatting the extracted check records into an electronic cash letter for 
10 transmission to the selected bank. 

16. The method of Claim 15 wherein the step of maintaining an information 
file on partner banks includes maintaining data identifying the banks and benefit 
sharing parameters. 

17. The method of Claim 16 wherein the step of maintaining an information 
file further includes the step of maintaining data on communications parameters. 

18. The method of Claim 15 wherein the step of selecting includes the step 
of building from the information file end-points from which to select killed bundles for 
extraction. 

19 . The method of Claim 15 wherein the step of selecting includes the step 
of selecting from the information file a bank; and wherein the step of extracting further 
includes reading from a second database storing kill bundle information with which to 
extract check records from the first database for transmission to endpoints automatically 
5 selected from the information file. 

20. The method of Claim 15 wherein the step of formatting includes 
formatting the records according to a predetermined format. 
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21 . The method of Claim 20 wherein the step of formatting further includes 
the step of determining which check records are available for benefit sharing. 

22. The method of Claim 15 further including the step of generating a 
settlement report, including expected benefit sharing. 

23. A method of processing an electronic cash letter received from a bank 
for expedited clearing of checks, the method comprising the steps of: 

receiving an electronic cash letter file from a sending bank containing check 
records; 

5 preprocessing the electronic cash letter file, the step of preprocessing including 

the steps of validating the electronic cash letter, checking for duplicate check items, 
balancing dollar amounts, and formatting for conforming to check processing and 
capture system (CPCS); 

capturing the electronic check records with a CPCS; 

-10 : — jwstmg~the-cheek-r^ 1 — 

capturing check information from paper checks in a subsequently received paper 
cash letter corresponding to the electronic cash letter; and 

reconciling the check records in the electronic cash letter with the captured 
check information and sorting the paper checks according to DDA cycles assigned 
15 during the capturing of the electronic check records. 

24. The method of Claim 23 further comprising the steps of: 

assigning item sequence numbers during the capturing of the electronic check 
records and the capturing of the paper checks; and 

creating a cross reference file of the item sequence numbers for each check 

5 item. 
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Foreword (This foreword is not pan of American National Standard X9.37-200I.) 

The purpose of this standard is to provide the financial industry with a format necessary to perform 
electronic check exchange (ECE). The format supports forward presentment, posting, return notification, 
and return requests, as well as existing customer information reporting products. The standard also 
supports multiple check clearing alternatives, e.g., bank-to-bank, bank-to-switch. 

The standard was designed to accommodate and work with existing data formats used to transmit check- 
related data, and to provide flexibility in accommodating future developments in check processing and 
check product offerings. The next phase of this standard, currently under development, will address 
adjustments and requests for information. 

Initially conceived as a necessary step in preparation for enactment of the Federal Reserve Board's 
Same-day Settlement proposal, it quickly became evident that the standard would benefit the financial 
industry in other ways. When fully implemented, the standard will enable financial institutions to cut 
processing costs and fraud losses by reducing the number of times a paper item must be handled, and by 
shortening the forward presentment and return cycle time frames. 

The standard was developed for the Accredited Standards Committee on Financial Services, X9, by the 
Subcommittee for Electronic Wholesale Payment Related & EDI Financial Services Standards, X9E. 

There are four annexes in this standard. Annexes A and B are normative and are considered part of this 
standard; annexes C and D are informative and are not considered part of this standard. Users of the 
standard are warned against using sections of the standard, especially the record layouts, out of context. 
Sections 1.0 through 6.8, and the normative annexes, provide information essential to the successful use 
of the record layouts and to the successful implementation of the standard itself. 

Suggestions for improvement of this standard will be welcome. They should be sent to the X9 Committee 
Secretariat, American Bankers Association, 1 120 Connecticut Avenue, NW., Washington, DC 20036. 

This standard was processed and approved for submission to ANSI by the Accredited Standards 
Committee on Financial Services, X9. Committee approval of this standard does not necessarily imply 
that all committee members voted for its approval. At the time it approved this standard, the X9 
committee had the following members: 

Harold G. Deal, X9 Chairman 
William E. Lyons, X9 Vice Chairman 
Cynthia L. Fuller, Managing Director 
Darlene ). Schubert, Program Manager 



Organization Represented Representative 

AC1 Worldwide Cindy Rink 

ACI Worldwide Jim Shaffer 

American Bankers Association Stephen Schutze 

American Express Company Bonnie Howard 

Bank One Corporation William Lyons 

Bank of America Gretchen Breiling 

Bank of America Harold Deal 

Bank Boston. Frank JarTe 

Bank Bostoa Richard Matthews 

Bank Bostoa Kevin Roden 

Certicom Corporation „ Donald Johnson 

Chase Manhattan Bank Francis Keenen 



iii 



Copvikm AnvffcM Kittonal Sundwfe iiuUtuw 

Prow 0*0 by WS \#Om *«M *W> ANSI 

No repraduSano* networking P»m«*J wo*** Uc«n*« trom tMS 



SOW »:MS Stanttam Start Pikum, 376913 
Nol la Res*H.01C 7/2007 07:57 46 M3T 



Organization Represented Representative 

Citibank Sy Rosen 

Cybersafe Corporation Glenda Barnes 

Deloitte & Touche Security Services LLC Jon Graff 

Deluxe Corporation Maury Jansen 

Diebold, Inc Sandy Morgan 

Discover Financial Services Inc Peggy Douds 

Discover Financial Services Inc Patsie Rinchiuso 

Ernst & Young LLP Geoffery Turner 

Ernst & Young LLP Richard Kastner 

Ernst & Young LLP Ralph Spencer Poore 

Federal Reserve Bank Gary Chaulklin 

Federal Reserve Bank Dexter Holt 

Financial Services Roundtable Kit Needham 

First Data Corporation Gene Kathol 

First Data Corporation Bill Clark 

Food Marketing Institute Ted Mason 

Griffin Consulting Phillip Griffin 

Griffin Consulting Harriette Griffin 

HP/VeriFone Brad McGuiness 

HP/VeriFone ; John Sheets 

IBM Corporation Harry Hankla 

IBM Corporation Don Harman 

KPMG Peat Marwick LLP Jeff Stapleton 

K.PMG Peat Marwick LLP Al Van Ranst, Jr. 

M. Blake Greenlee Associates Blake Greenlee 

MasterCard International Ron Karlin 

MasterCard International Melinda Yee 

Mellon Bank, N.A Genien Carlson 

Mellon Bank, N.A David Taddeo 

Merrill Lynch John Roy 

Merrill Lynch Jennifer Smith 

National Association of Convenience Stores Robert Swanson 

National Association of Convenience Stores Ten Richmond 

National Security Agency Greg Bergren 

National Security Agency Sheila Brand 

NCR Corporation Steve Stevens 

New York Clearing House Vincent DeSantis 

Pitney Bowes Inc Leon Pintsov 

PriceWaterhouseCoopcrs John Hunt 

PriceWtarehouseCoopers JeffZimmerman 
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Unisys Corporation Thomas Hayosh 

Unisys Corporation James Graziano 

VISA International William Chen 

Wells Fargo Bank „ „ Terry Leahy 

Xcert International Inc Marc Bra nc hand 

Xcert Internatioanl Inc Young Etheridge 

Xcert International Inc „ Sandra Lambert 



The X9B subcommittee on Check Processing had the following members: 
Mr. Christopher Dowdell, Chairman, BancTec, Inc. 
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AMERICAN NATIONAL STANDARD 

American National Standard 
for Financial Services — 

Specifications For 
Electronic Check 
Exchange 

1 Scope, purpose, and application 

1.1 Scope 

This standard establishes the file sequences, record 
types, and field formats to be used for the electronic 
exchange of check MICR line and associated check 
processing data. 

This standard docs not address operational, 
implementation, or settlement issues. These issues 
may include, but are not limited to: choice of 
compression (e.g., Blank compression), encryption 
(e.g., DES, Clipper), transmission specifications (e.g., 
protocols, tine spreads), and data representation (e,g., 
ASCII, EBCDIC). The informative annexes attached 
to this standard provide information which may prove 
useful to those planning on implementing the 
standard. 

1.2 Presentment disclaimer 

"Presentment" is used throughout this standard in a 
colloquial sense only: to refer to or to describe an 
operational process, the movement of checks and 
check* related data from a collecting bank to a paying 
bank. 

In no instance shall use of the term "presentment" in 
the standard be construed as a legal definition of 
presentment, or as a description of when presentment 
as a legal event occurs. Nor does its use in any way 
define the legal rights and responsibilities of parties 
participating in the check clearing process, or parties 
otherwise interested in a check. 

This standard shall not be used by parties in dispute 
to define legal standards of conduct in the check 
clearing process, and cannot be relied upon in that 
context. Parties interested in the legal standards 
governing the check clearing process should consult 
the Uniform Commercial Code, Regulation CC - 
Availability of Funds and Collection of Checks, 
Federal Reserve Operating Circulars, Clearinghouse 
rules, other clearing agreements, relevant case law, 
and other sources of applicable law. 
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I J Purpose and application 

The purpose of this standard is to provide a structure 
to facilitate electronic exchange of check data for the 
purposes of forward check presentment, return item 
notification (whether forward presentment occurred 
via electronic exchange or via traditional physical 
means), and return of truncated items. 



2 References 

ANSI X3.23 (1985) American National Standard for 
Information Systems - Programming Language - 
COBOL 

ANSI X9.I3 (1999) Specifications for Placement and 
Location of MICR Printing 

ISO 3166-1981 Codes for the representation of 
names of countries 

X9-TG-2 (R1995) Understanding and Designing 
Checks 

12CFR229 Regulation CC - Availability of Funds 
and Collection of Checks 



3 General definitions 

3.1 account number: The number used by a 
bank to identify a customer's account It is usually 
contained in the On Us Field of the MICR line. 

3.2 adjustment: An accounting entry to correct 
errors on cash letters or checks. 

3.3 all electric check: a generic term 
designating a negotiable instrument that has only 
existed in an electronic form. 

3.4 amount Held: Positions 1-12 of the MICR 
line on a document, where the dollar amount is 
encoded. 

3.5 auxiliary on us field: A variable format, 
optional field in the MICR line, located to the left of 
the Routing field, used at the discretion of the On -Us 
financial institution. 

3.6 bank of first deposit (BFD): The first 
institution, legally chartered or licensed to collect 
or pay checks deposited by a company or individual, 
in which a check has been deposited. It is also the 
institution to which a check would be returned in the 
event of non-payment, for return to the depositor. 
Also referred to as the depositary bank. 

3.7 box: A physical package used for storing 
and transporting checks. A typical box holds about 
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3000 checks. The box total also may serve as an 
additional control total on the cash letter listing. 

3.8 bundle: A subset of a cash letter usually 
containing about 300-400 checks. The dollar amount 
of the bundle serves as a control total and is listed on 
the cash letter. 

3.9 cash letter: A group of checks sent by a 
bank or its agents to another bank, a clearing house, 
or a Federal Reserve office. A cash letter contains a 
number of negotiable items, usually checks, 
accompanied by a transmittal letter that lists the 
dollar totals of the check bundles. 

3.10 electronic check exchange (ECE): The 
exchange of check information electronically, in lieu 
of or in addition to the exchange of paper checks. For 
forward presentment, usually referred to as electronic 
check presentment (ECP). 

3.11 ECE Institution: The institution that creates 
and sends the electronic cash letter information. 

3.12 external processing code (EPC) field An 
optional, single digit field located to the left of the 
routing field on a check. The EPC field is used for 
special purposes as authorized by the Accredited 
Standards Committee X9B. 

3.13 fixed format: A term applied to the required 
and optional fields for which the location, digit 
sequence and structure are completely specified. 

3.14 magnetic ink character recognition 
(MICR): The common machine language speci-ficd 
for the paper-based payment transfer system. It 
consists of magnetic ink printed characters of a 
special design, called the E 1 3 B 
font, that can be recognized by high speed magnetic 
recognition equipment. 

3.15 On Us field The MICR print band area 
between the closing amount symbol and the opening 
routing symbol. Arrangement of the on us field is 
variable, specified by the bank on which the check is 
written. It may include such information as the user's 
account number, a consecutive number, or 
processing code. 

3.16 payor: The party issuing a check. The payor 
also is known as the maker or writer. 

3.17 payor bank: The institution by or through 
which a check is payable. The payor bank is also 
referred to as paying bank. 

3.18 presentment: The operational process of 
moving checks and check related data from a 
collecting bank to a paying bank. 
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3.19 qualified return check (QRC): A return 
check prepared for automated processing. It is 
stripped or placed in a carrier envelope and encoded 
with the routing number of the depository bank, the 
dollar amount of the check, and the value 4 2* in 
position 44 of the MICR line. 

3.20 Regulation CC (12 CFR part 229): The 
regulation adopted by the Board of Governors of the 
Federal Reserve System to implement the Expedited 
Funds Availability Act (12 U.S.C. 4001-4010). The 
regulation specifies, among other things, minimum 
availability standards for deposited funds and rales 
designed to expedite check collections and returns. 

3.21 return Item A check returned unpaid by 
the payor bank. It may be returned to the BFD 
directly or through an intermediary. 

3.22 routing field Positions 33 through 43 of the 
MICR line that cotains the routing number. 

3.23 routing number: The nine digit numeric 
identified of a financial institution as assigned by the 
American Bankers Association or its agent. Routing 
numbers arc used for routing purposes on checks, and 
virtually all other MICR documents, such as deposit 
tickets and batch tickets. A specific numeric series is 
reserved for internal bank usage. 

3.24 same day settlement A set of amendments 
to Regulation CC (12 CFR part 229) which specifies 
conditions under which a payor bank must settle for a 
check with a presenting bank in same -day funds. 

3.25 short name: The abbreviated name assigned 
to a bank, typically by the Federal Reserve. 

3.26 transaction code: An optional code usually 
located in the On -Us field that can identify document 
type or handling. Usage is specifieid by the financial 
institution on which the check is written. 

3.27 truncation: Procedures in which the 
physical check is retained or delayed by the 
depository or collecting bank. 



4 File structure 

The use of record types in the standard allows a file 
to be structured in a manner closely matching a 
physical cash fetter. This section describes: a) the 
different types of records which are mandatory and 
conditional within a file; b) the organization of a file; 
and c) representative examples of how files are 
structured. 
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4.1 Record types 

The following are record types established for ECE: 

File Header Record (Type 01 ) 

Cash Lelter Header Record (Type 10) 

Bundle Header Record (Type 20) 

• Check Detail Record (Type 25) 

Check Detail Addendum A Record (Type 26) 
Check Detail Addendum B Record (Type 27) 
Return Record (Type 3 1 ) 
Return Addendum A Record (Type 32) 

• Return Addendum B Record (Type 33) 
Return Addendum C Record (Type 34) 
Bundle Control Record (Type 70) 
Box Summary Record (Type 75) 
Routing Number Summary Record (Type 85) 

• Cash Letter Control Record (Type 90) 
File Control Record (Type 99) 

4.2 File structure requirements 

In general, an ECE file contains one or more cash 
letters. Cash letters contain one or more bundles 
which arc destined for the institutions identified in 
the Cash Letter Header Records as the final 
destinations. Bundles within cash letters contain the 
check detail records or return records. Within a 
particular cash letter, check detail records and return 
records cannot be commingled. 

As the various records are defined, reference to 
certain fields in various records are made. The data 
elements and definitions for each record type are 
described in sections 7 through 2 1 . 

4.2.1 File Header Record 

a) The File Header Record, shall always appear 
as the first record in a file. 

4.2.2 Cash Utter Header Record 

a) The Cash Letter Header Record shall be present 
and always follows a File Header 
Record, or a Cash Letter Control Record when a 
file contains multiple cash letters. 

b) A Cash Letter Header Record contains an 
indicator, called the Collection Type Indicator, 
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which identifies the type of records present 
within the cash letter. 

4.2 3 Bundle Header Record 

a) The Bundle Header Record shall be present and 
always follows a Cash Letter Header Record, a 
Bundle Control Record, or a Box Summary 
Record. 

b) A Bundle Header Record contains an indicator, 
called the Collection Type Indicator, which 
identifies the type of records present within the 
bundle. The Collection Type Indicator in a 
Bundle Header Record shall be set to the 
same value as the Collection Type Indicator in 
the Cash Letter Header Record within which the 
bundle is contained. 

4.2.4 Check Detail Record 

a) The Check Detail Record shall always follow a 
Bundle Header Record, a Check Detail Record, or a 
Check Detail Addendum Record. 

b) It shall be present only when the Collection Type 
Indicator is set to "forward presentment" or 
"forward presentment - same-<lay settlement" in 
a Bundle Header Record. 

c) There shall be one record for each check. 

4.2.5 Check Detail Addendum A Record 

a) The Check Detail Addendum A Record, when 
used, shall always follow its immediately 
corresponding Check Detail Record. 

b) Only one Check Detail Addendum A Record is 
permitted for a Check Detail Record, when the 
Check Detail Record Addendum Count is set to 
one or two in the Check Detail Record 
immediately preceding the Check Detail 
Addendum A Record. 

4.2.6 Check Detail Addendum B Record 

a) The Check Detail Addendum B Record, when 
used, shall always follow its immediately 
corresponding Check Detail Record when the 
Check Detail Addendum Count is set to one on 
the Check Detail Record immediately 
preceding the Check Detail Addendum B Record 
and a Check Detail Addendum A Record is not 
used. 

b) When the Check Detail Addendum Count is set 
to two in the Check Detail Record, the Check 
Detail Addendum B Record shall always follow 
its immediately corresponding Check Detail 
Addendum A Record. 
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4.2.7 Return Record 

a) The Return Record shall always follow a Bundle 
Header Record, a Return Record, a Return 
Addendum A Record, a Return Addendum B 
Record, or a Return Addendum C Record. 

b) It shall be present only when the Collection Type 
Indicator is preliminary return information*, 
* return notification*, or * return request for 
truncated items* in a Bundle Header Record. 

c) There shall be one record for each return. 

. 4.2.8 Return Addendum A Record 

= a) The Return Addendum A Record, when used, 
shall always follow its immediately 
corresponding Return Record. 

b) No more than one Return Addendum A Record 
may be present for a corresponding Return 
Record when the Return Addendum count is set 
to one, two, or three in the Return Record 
immediately preceding the Return Addendum A 
Record. 



4.2.9 Return Addendum B Record 

a) The Return Addendum B Record, when used, 
shall always follow its immediately 
corresponding Return Record when the Return 
Addendum Count is set to one in the Return 
Record immediately preceding the Return 
Addendum B Record and a Return Addendum A 
Record and a Return Addendum C Record arc 
not used. 

b) When the Return Addendum Count is set to two 
in the Return Record, the Return Addendum B 
Record shall always follow its immediately 
corresponding Return Adden-dum A Record or 
shall be followed by a Return Addendum C 
Record. 

4.2.10 Return Addendum C Record 

a) The Return Addendum C Record, when used, 
shall always follow its immediately 
corresponding Return Record when the Return 
Addendum Count is set to one in the Return 
Record immediately preceding the Return 
Addendum C Record and a Return Addendum A 
Record and Return Addendum B Record are not 
used. 

b) When the Return Addendum Count is set to two 
in the Return Record, the Return Addendum C 
Record shall always follow its immediately 
corresponding Return Adden-dum A Record and 
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a Return Addendum B Record is not used or the 
Return Addendum C Record shall always follow 
its immediately corresponding Return 
Addendum B Record and a Return Addendum A 
Record is not used. 

c) When the Return Addendum Count is set to three 
in the Return Record, the Return Addendum C 
Record shall always follow its immediately 
corresponding Return Adden-dum A Record and 
Return Addendum B Record. 

4.2.1! Bundle Control Record 

a) The Bundle Control Record shall be present as 
the last record of the bundle, completing the 
bundle begun by the preceding Bundle Header 
Record. 

b) It shall follow a Check Detail Record, a Check 
Detail Addendum Record, a Return Record, a 
Return Addendum A Record, or a Return 
Addendum B Record, or a Return Addendum C 
Record. 

4.2.12 Box Summary Record 

a) The Box Summary Record, when used, shall 
always follow a Bundle Control Record. 

4.2.13 Routing Number Summary Record 

a) The Routing Number Summary Record, when 
used, shall always follow: i) the final Bundle 
Control Record of the cash letter; ii) a Box 
Summary Record, when used, of the final 
Bundle Control Record of the cash letter; or iii) 
another Routing Number Summary Record. 

b) It shall be present only when the Collection Type 
Indicator is * forward presentment* or * forward 
presentment - same-day settlement' in the Cash 
Letter Header Record. 

4.2.14 Cash Letter Control Record 

a) The Cash Letter Control Record shall be present 
as the last record in a cash letter, completing the 
cash letter begun by the preceding Cash Letter 
Header Record. 

b) When the Empty Cash Letter Indicator in the 
preceding Cash Letter Header Record is blank or 
set to *N*. the Cash Letter Control Record shall 
always follow: i) the final Bundle Control 
Record of the cash letter; ii) a Box Summary 
Record, when used, of the final Bundle Control 
Record; or iii) the final Routing Number 
Summary Record, when used, of the cash letter. 

c) When the Empty Cash Letter Indicator in the 
preceding Cash Letter Header Record is set to 
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4 Y\ the Cash Letter Control Record shall always 
follow the Cash Letter Header Record. 

4.2.1 5 File Control Record 

a) The File Control Record shall be present as the 
last record of the file completing the file begun 
by the preceding File Header Record. 
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4.3 Examples 

The following are examples of ECE file structures which meet the requirements of the standard. The examples 
shown are representative samples of file structures and are not the only structures permitted. 

4.3.1 Example 1 

File with one forward presentment cash letter. 

FILE HEADER RECORD 

Cash Letter Header Record 

Bundle Header Record (first bundle of cash letter) 

Check Detail Record (first item of first bundle) 
Check Detail Record (second item of first bundle) 



Check Detail Record (last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Check Detail Record (first item of second bundle) 
Check Detail Record (second item of second bundle) 



Check Detail Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 
II 
0 
0 

Bundle Header Record (last bundle of cash letter) 

Check Detail Record (first item of last bundle) 
Check Detail Record (second item of last bundle) 

II 

I 

II 

Check Detail Record (last item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record 
FILE CONTROL RECORD 
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4.3.2 Example 2 

File with multiple forward presentment cash letters. 
FILE HEADER RECORD 

Cash Letter Header Record (first cash letter of file) 
Bundle Header Record (first bundle of cash letter) 

Check Detail Record (first item of first bundle) 
Check Detail Record (second item of first bundle) 

0 

II 
II 

Check Detail Record (last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Check Detail Record (first item of second bundle) 
Check Detail Record (second item of second bundle) 

II 

II 

II 

Check Detail Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 
II 
II 

a 

Bundle Header Record (last bundle of cash letter) 

Check Detail Record (first item of last bundle) 
Check Detail Record (second item of last bundle) 

II 
II 
II 

Check Detail Record (last item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record (end of first cash letter) 
Cash Letter Header Record (second cash letter of file) 
Bundle Header Record (first bundle of cash letter) 
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Check Detail Record (first item of first bundle) 
Check Detail Record (second item of first bundle) 

II 

II 
II 

Check Detail Record (last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Check Detail Record (first item of second bundle) 
Check Detail Record (second item of second bundle) 

II 

II 

II 

Check Detail Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 

n 
n 
ii 

Bundle Header Record (last bundle of cash letter) 

Check Detail Record (first item of last bundle) 
Check Detail Record (second item of last bundle) 

II 

II 

II 

Check Detail Record (last item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record (end of second cash letter) 
II 
II 
II 

Cash Letter Header Record (last cash letter of file) 

Bundle Header Record (first bundle of cash letter) 

Check Detail Record (first item of first bundle) 
Check Detail Record (second item of first bundle) 

a 



Check Detail Record (last item of first bundle) 
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Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Check Detail Record (first item of second bundle) 
Check Detail Record (second item of second bundle) 

II 

II 

II 

Check Detail Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 
I) 
I) 
II 

Bundle Header Record (last bundle of cash letter) 

Check Detail Record (first item of last bundle) 
Check Detail Record (second item of last bundle) 

II 

0 

I 

Check Detail Record (last item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record (end of last cash letter) 
FILE CONTROL RECORD 
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4J.3 Example 3 

File with multiple forward presentment cash letters containing Check Detail Addendum A Records, Check Detail 
Addendum B Records, Box Summary Records, and Routing Number Summary Records. 



FILE HEADER RECORD 

Cash Letter Header Record (first cash letter of file) 

Bundle Header Record (first bundle of cash letter) 

Check Detail Record (first item of first bundle) 
Check Detail Record (second item of first bundle) 

Check Detail Addendum A Record (for second item of first bundle) 

Check Detail Record (third item of first bundle) 
Check Detail Record (fourth item of first bundle) 
Check Detail Record (fifth item of first bundle) 

Check Detail Addendum A Record (for fifth item of first bundle) 

Check Detail Record (sixth item of first bundle) 

Check Detail Addendum A Record (for sixth item of first bundle) 

II 
II 
II 

Check Detail Record (last item of first bundle) 

Check Detail Addendum B Record (for last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Check Detail Record (first item of second bundle) 
Check Detail Record (second item of second bundle) 
Check Detail Record (third item of second bundle) 
Check Detail Record (fourth item of second bundle) 

Check Detail Addendum B Record (for fourth item of second bundle) 

Check Detail Record (fifth item of second bundle) 

Check Detail Addendum A Record (for fifth item of second bundle) 
Check Detail Addendum B Record (for fifth item of second bundle) 

Check Detail Record (sixth item of second bundle) 

Check Detail Addendum A Record (for sixth item of second bundle) 

Check Detail Record (seventh item of second bundle) 
Check Detail Record (eighth item of second bundle) 

II 
II 
II 
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Check Detail Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 
t 

0 

1 

Bundle Header Record (last bundle of cash letter) 

Check Detail Record (first item of last bundle) 
Check Detail Record (second item of last bundle) 



II 

Check Detail Record (lost item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Routing Number Summary Record 

(for a routing number appearing in the Check Detail Records in the bundles within this cash letter) 
Routing Number Summary Record 

(for another routing number appearing in the Check Detail Records in the bundles within this cash letter) 
Routing Number Summary Record 

(for another routing number appearing in the Check Detail Records in the bundles within this cash letter) 
Cash Letter Control Record (end of first cash letter) 
Cash Letter Header Record (second cash letter of file) 
Bundle Header Record (first bundle of cash letter) 

Check Detail Record (first item of first bundle) 
Check Detail Record (second item of first bundle) 

II 



Check Detail Record (last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Check Detail Record (first item of second bundle) 
Check Detail Record (second item of second bundle) 
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Check Detail Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 

II 
II 
II 

Bundle Header Record (28th bundle of cash letter) 

Check Detail Record (first item of 28ih bundle) 
Check Detail Record (second item of 28th bundle) 

II 

II 

0 

Check Detail Record (last item of 28th bundle) 

Bundle Control Record (end of 28th bundle of cash letter) 

Box Summary Record (summary of first through 28th bundle of cash letter) 

Bundle Header Record (29th bundle of cash letter) 

Check Detail Record (first item of 29th bundle) 
Check Detail Record (second item of 29th bundle) 

II 

II 
II 

Check Detail Record (last item of 29th bundle) 
Bundle Control Record (end of 29th bundle of cash letter) 
II 
II 

Bundle Header Record (last bundle of cash letter) 

Check Detail Record (first item of last bundle) 
Check Detail Record (second item of last bundle) 

y 
it 
ii 

Check Detail Record (last item of last bundle) 

Bundle Control Record (end of last bundle of cash letter) 

Box Summary Record (summary of 29th through last bundle of cash letter) 

Routing Number Summary Record 

(for a routing number appearing in the Check Detail Records in the bundles within this cash letter) 
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Routing Number Summary Record 

(for another routing number appearing in the Check Detail Records in the bundles within this cash letter) 

Cash Letter Control Record (end of second cash letter) 

II 
II 

II 

Cash tetter Header Record (last cash letter of file) 

Bundle Header Record (first bundle of cash letter) 

Check Detail Record (first item of first bundle) 
Check Detail Record (second item of first bundle) 

II 

II 

II 

Check Detail Record (last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Check Detail Record (first item of second bundle) 
Check Detail Record (second item of second bundle) 

I 

II 

0 

Check Detail Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 
II 
I 
I 

Bundle Header Record (last bundle of cash letter) 

Check Detail Record (first item of last bundle) 
Check Detail Record (second item of last bundle) 

II 
II 
II 

Check Detail Record (last item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record (end of last cash letter) 
FILE CONTROL RECORD 
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4.3.4 Example 4 

File with multiple return cash letters containing Return Addendum A Records, Return Addendum B Records, and 
Return Addendum C Records. 

FILE HEADER RECORD 

Cash Letter Header Record (first cash letter of file) 

Bundle Header Record (first bundle of cash letter) 

Return Record (first item of first bundle) 
Return Record (second item of first bundle) 

Return Addendum A Record (for second item of first bundle) 
Return Addendum B Record (for second item of first bundle) 
Return Addendum C Record (for second item of first bundle) 

Return Record (third item of first bundle) 
Return Record (fourth item of first bundle) 

Return Addendum A Record (for fourth item of first bundle) 
Return Addendum B Record (for fourth item of first bundle) 
Return Addendum C Record (for fourth item of first bundle) 

Return Record (fifth item of first bundle) 

Return Addendum B Record (for fifth item of first bundle) 

Return Record (sixth item of first bundle) 

Return Addendum A Record (for sixth item of first bundle) 
Return Addendum C Record (for sixth item of first bundle) 

Return Record (seventh item of first bundle) 

Return Addendum B Record (for seventh item of first bundle) 
Return Record (eighth item of first bundle) 

Return Addendum A Record (for eighth item of first bundle) 



Return Record (last item of first bundle) 

Return Addendum A Record (for last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Return Record (first item of second bundle) 
Return Record (second item of second bundle) 
Return Record (third item of second bundle) 
Return Record (fourth item of second bundle) 

Return Addendum C Record (for fourth item of second bundle) 

Return Record (fifth item of second bundle) 

Return Addendum A Record (for fifth item of second bundle) 
Return Addendum B Record (for fifth item of second bundle) 



II 
II 
II 
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Return Record (sixth item of second bundle) 

Return Addendum B Record (for sixth item of second bundle) 

Return Record (seventh item of second bundle) 
Return Record (eighth item of second bundle) 

II 

II 

I 

Return Record (last item of second bundle) 

Return Addendum A Record (for last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 
II 

u 
II 

Bundle Header Record (last bundle of cash letter) 

Return Record (first item of last bundle) 
Return Record (second item of last bundle) 

II 

I 

II 

Return Record (last item of last bundle) 

Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record (end of first cash letter) 
Cash Letter Header Record (second cash letter of file) 

Bundle Header Record (first bundle of cash letter) 

Return Record (first item of first bundle) 
Return Record (second item of first bundle) 

II 
II 
II 

Return Record (last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Return Record (first item of second bundle) 
Return Record (second item of second bundle) 

II 

II 
II 
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Return Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 

II 
II 
II 

Bundle Header Record (last bundle of cash letter) 

Return Record (first item of last bundle) 
Return Record (second item of last bundle) 

II 
II 
II 

Return Record (last item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record (end of second cash letter) 

II 
II 
I 

Cash Letter Header Record (last cash letter of file) 
Bundle Header Record (first bundle of cash letter) 
Return Record (first item of first bundle) 

Return Addendum A Record (for first item of first bundle) 
Return Record (second item of first bundle) 
II 
II 
II 

Return Record (last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Return Record (first item of second bundle) 
Return Record (second item of second bundle) 

Return Addendum A Record (for second item of second bundle) 
Return Addendum B Record (for second item of second bundle) 

0 

II 
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Return Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 
II 
II 
II 

Bundle Header Record (last bundle of cash letter) 

Return Record (first item of last bundle) 

Return Addendum A Record (for first item of last bundle) 
Return Addendum B Record (for first item of last bundle) 

Return Record (second item of last bundle) 

D 

n 
ii 

Return Record (last item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record (end of last cash letter) 
FILE CONTROL RECORD 
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4.3.5 Example 5 

File with multiple forward presentment and return cash letters records. Refer to the File Structure Requirements 
(Section 4.2) and the previous examples for the structure of bundles. 

FILE HEADER RECORD 

Cash Letter Header Record (first cash tetter of file) 

II 

{bundles of forward items} 
II 

Cash Letter Control Record (end of first cash letter) 
Cash Letter Header Record (second cash letter of file) 

II 

{bundles of forward items} 
II 

Cash Letter Control Record (end of second cash letter) 
Cash Letter Header Record (third cash letter of file) 

II 

{bundles of return items} 

II 

Cash Letter Control Record (end of third cash letter) 
Cash Letter Header Record (fourth cash letter of file) 

II 

{bundles of forward items} 

II 

Cash Letter Control Record (end of fourth cash letter) 
Cash Letter Header Record (fifth cash letter of file) 
II 

{bundles of forward items} 
0 

Cash Letter Control Record (end of fifth cash letter) 
Cash Letter Header Record (sixth cash letter of file) 
II 

{bundles of return items} 
II 
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Cash Letter Control Record (end of sixth cash letter) 
» 
I 
I 

Cash Letter Header Record (last cash letter of file) 

II 

{bundles of forward items) 

0 

Cash Letter Control Record (end of last cash letter) 
FILE CONTROL RECORD 
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4.3.6 Example 6 

File with multiple forward presentment cash letters which contain bundles of records and cash letters which are 
empty. 

FILE HEADER RECORD 

Cash Letter Header Record (first cash letter of file) 

Bundle Header Record (first bundle of cash letter) 

Check Detail Record (first item of first bundle) 
Check Detail Record (second item of first bundle) 

I 

II 
II 

Check Detail Record (last item of first bundle) 

Bundle Control Record (end of first bundle of cash tetter) 
Bundle Header Record (second bundle of cash letter) 

Check Detail Record (first item of second bundle) 
Check Detail Record (second item of second bundle) 

II 

II 

II 

Check Detail Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 
II 

II 
II 

Bundle Header Record (last bundle of cash letter) 

Check Detail Record (first item of last bundle) 
Check Detail Record (second item of last bundle) 

II 
II 

II 

Check Detail Record (last item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record (end of first cash letter) 
Cash Letter Header Record (second cash letter of file) 



This is an empty cash letter. Therefore, no bundles are present. 



Cash Letter Control Record (end of second cash letter) 
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I 

II 

Cash Letter Header Record (last cash letter of file) 

Bundle Header Record (first bundle of cash letter) 

Check Detail Record (first item of first bundle) 
Check Detail Record (second item of first bundle) 

II 

II 

II 

Check Detail Record (last item of first bundle) 

Bundle Control Record (end of first bundle of cash letter) 
Bundle Header Record (second bundle of cash letter) 

Check Detail Record (first item of second bundle) 
Check Detail Record (second item of second bundle) 

II 

II 

II 

Check Detail Record (last item of second bundle) 
Bundle Control Record (end of second bundle of cash letter) 
II 
II 

n 

Bundle Header Record (last bundle of cash letter) 

Check Detail Record (first item of last bundle) 
Check Detail Record (second item of last bundle) 

II 
II 
II 

Check Detail Record (last item of last bundle) 
Bundle Control Record (end of last bundle of cash letter) 
Cash Letter Control Record (end of last cash letter) 
FILE CONTROL RECORD 
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5 Data and field specifications 
5.1 Generic data types 

The following arc the names, abbreviations, and 
definitions of the characters permitted in the 
standard. 

5.1.1 Alphabetic (a) 

The alphabetic characters are the upper case letters A 
through Z, the lower case letters a through z, and the 
blank (space) character. When lower case letters are 
used, they shall be interpreted to have the same 
meaning as their respective upper case letters, e.g., no 
distinction shall be made between the upper case 
letter A and the lower case letter a. 

5.1.2 Numeric (n) 

The numeric characters are the numbers zero (0) 
through nine (9). 

5.13 Blank (b) 

The blank character is defined in EBCDIC with the 
hexadecimal value '40' and in ASCII with the 
hexadecimal value 4 20'; also referred to as a space. 

5.1.4 Special characters (s) 

Special characters are any printable characters with 
an EBCDIC hexadecimal value greater than *3F' or 
ASCII value greater than MF' that are neither 
alphabetic, nor numeric, nor blank. 

5.1.5 Alphameric (an) 

An alphameric character is any of the alphabetic or 
numeric characters. 

5.1.6 Alphameric/special (ans) 

An alphameric/special character is any one of the 
alphabetic, numeric, or special characters. 

5.1.7 Numericblank(nb) 

A numericblank character is any one of the numeric 
characters or the blank character. 

5.2 Special MICR line data types 

The MICR line on a check is composed of a series of 
symbols. The MICR symbols for numbers shall be 
represented by the numeric values zero (0) through 
nine (9). However, the MICR symbols for delineation 
of data on the MICR line do not have any graphic 
equivalents. 

Therefore, certain special characters shall be used to 
interpret these MICR symbols. These special 
characters shall have these special meanings only 
when used in fields directly read from the MICR line. 
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When these same special characters are used 
elsewhere in other fields they shall represent their 
actual value. 

5.2.1 Asterisk (*) 

The asterisk character shall be used to represent the 
presence of MICR when the processing system 
cannot interpret the MICR as a specific valid MICR 
character. 

5.2.2 Dash (-) 

The dash character shall be used to represent the 
presence of the MICR symbol *dash\ 

5.2.3 Forward slash(/) 

The forward slash character shall be used to represent 
the presence of the MICR symbol *on us'. 

5.2.4 Numericblank/special MICR (nbsm) 

A numericblank/special character is any one of the 
numeric characters, the blank character, or asterisk 
character. 

5.2.5 Numericblank/special MICR On us 
(nbsmos) 

A numericblank/special MICR On us character is any 
one of the numeric characters, the blank character, 
the asterisk character, the dash character, or the slash 
character. 

S3 Fill data 

Fill data are any characters used to fill up unused 
bytes in a field. Fill characters shall be Blanks or 
Zeros. 

5.4 Data justification 

Justification is the act of aligning data as it is placed 
into a field, based on its right or left- most character 

5.4.1 Right Justification 

A field is right justified when the data is aligned 
based on its right-most character. 

5.4.2 Left justification 

A field is left justified when the data is aligned based 
on its left- most character. 

5.5 General field orientation 

The following shall apply to all fields on all records 
in the standard, except for those detailed in section 
5.6, Exception Fields. 

a) A Held defined as alphameric, alphabetic, 
alphameric/special, or numericblank shall be left 
justified. 
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b) A field defined as alphameric, alphabetic, 
alphameric/special, or numericblank shall be 
blank filled. 

c) A field defined as numeric shall be right 
justified. 

d) A field defined as numeric shall be zero filled. 

e) A field defined as numericblank/special MICR 
or numericblank/special MICR On Us shall be 
right justified. 

0 A field defined as numericblank/special MICR 
or numericblank/special MICR On Us shall be 
blank filled. 

g) If a field is mandatory and has predefined values, 
it shall contain one of these predefined values or 
it is invalid. 

h) If a field is conditional, is used and has 
predefined values, it shall contain one of these 
predefined values or it is invalid. 

i) All fields that are conditional and are not used 
shall be filled with Blanks. 

5.6 Exception fields 

The following fields are exceptions to the above. 

5.6.1 Check Detail Addendum A Record 

a) The deposit account number at BFD field shall 
be right justified and blank filled 

5.6.2 Return Record Addendum A Record 

a) The deposit account number at BFD field shall 
be right justified and blank filled 

5.7 User fields 

Most records of the ECE file provide for user fields. 
Users of the standard utilize these fields at their 
discretion. The standard does not define particular 
uses for or the internal contents of these fields. In 
many cases, the user fields within the records are 
more than one character in length. Users are free to 
use the field as a single field or divide it into multiple 
fields. 

6 Table headings and title descriptions 

Sections 7.0 through 19.0 contain the ECE records. 
The table headings and the titles used in those 
sections are described below. 

6.1 Field 

This column contains sequential field numbers. 

6.2 Field name 

This column contains the name of the field. 
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63 Usage 

This column identifies whether the field shall be 
mandatory or conditional: 

a) Mandatory (M) - the data element shall always 
be present; and 

b) Conditional (C) - the data element shall be 
present only under certain conditions. 

6.4 Position 

This column contains the starting and ending location 
of each field within the record. 

6.5 Size 

This column contains the number of characters within 
the field. 

6.6 Type 

This column identifies the kind of data that shall be 
valid for the field. The type indicates, in general, the 
allowable characters permitted, but may be restricted 
to a subset of the type. When a restriction exists, the 
allowable character or characters arc defined in the 
section where the field is described. 

6.7 Format 

This title describes the unique structure for a 
particular field, when one exists. 

6\8 Defined values 

This title serves two purposes. For some fields, it 
provides a specific value or a list of specific values 
and the interpretation of each value. Second, for 
some fields it provides the allowable range of values. 
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7 File Header Record (Type 01) 

The File Header Record is mandatory and contains fourteen fields. It is the first record of an electronic check 
exchange file. The data in the fields are created by the institution sending the file, the immediate origin institution. 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE 


1 


Record type 


M 


01 -02 


2 


N 


2 


Standard level 


M 


03-04 


2 


N 


3 


Test file indicator 


M 


05-05 


1 


A 


4 


Immediate destination 

mil tin p number 


M 


06-14 


9 


N 


5 


Immediate origin 
routing number 


M 


15-23 


9 


N 


6 


File creation date 


M 


24-31 


8 


N 


7 


File creation time 


M 


32-35 


4 


N 


8 


Resend indicator 


M 


36-36 


1 


A 


9 


Immediate destination 
name 


C 


37-54 


18 


A 


10 


Immediate origin name 


C 


55-72 


18 


A 


11 


File ID modifier 


C 


73-73 


I 


AN 


12 


Country code 


C 


74-75 


2 


A 


13 


User field 


C 


76-79 


4 


ANS 


14 .. 


Reserved 


M 


80-80 


1 


B 
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7.1 Record type 

A code that identifies the type of record. 

Usage: Mandatory 

Position: 01-02 

Size: 2 

Type: N Numeric 

Defined 

Values: *01' File Header Record 

7.2 Standard level 

A code that identifies the version of the standard used 
to create the electronic check exchange file. 

Usage: Mandatory 

Position: 03 - 04 

Size: 2 

Type: N Numeric 

Defined 



Values: 



7.3 



*0rX9.37-l994 
'02* X9.37-200I 

Test file indicator 



A code that indicates whether the file being 
transmitted is a test file or a production file. 

Usage: Mandatory 

Position: 05-05 

Size: 1 

Type: A Alphabetic 
Defined 

Values: 'P* Production File 
4 T* Test File 

7.4 Immediate destination routing number 

A number that identifies the institution that receives 
the electronic check exchange file. 

Usage: Mandatory 

Position: 06-14 

Size: 9 

Type: N Numeric 

Formal: TTTTAAAAC, where: 

li i i Federal Reserve Routing Symbol 



AAAA ABA Institution Identifier 
C Check Digit 

7.5 Immediate origin routing number 

A number that identifies the institution that originates 
the electronic check exchange file. 

Usage: Mandatory 

Position: 15-23 

Size: . 9 

Type: N Numeric 

Format: TTTTAAAAC, where: 

i tit Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 
C Check Digit 

7.6 File creation date 

The year, month, and day that the immediate origin 
institution creates the electronic check exchange file. 

Usage: Mandatory 

Position: 24-31 

Size: 8 

Type: N Numeric 

Format: YYYYMMDD, where: 

YYYY year 

MM month 

DD day 

Defined 

Values: YYYY * 1993* through '9999' 
MM '0T through M2* 
DD 4 0T through '3P 

7.7 File creation time 

The time the immediate origin institution creates the 
electronic check exchange file. 

Usage: Mandatory 

Position: 32-35 

Size: 4 

Type: N Numeric 

Format: hhmm, where: 

hh hour 
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mm minute 

Defined 

Values: hh '0<T through '23* 
mm '00' through *59* 
7.8 Resend Indicator 

A code that indicates whether the electronic check 
exchange file has been previously transmitted in its 
entirety. 

Usage: Mandatory 

Position: 36-36 

Size: I 

Type: A Alphabetic 

Defined 

Values: *Y' resend file 

*N* original file 

7*9 Immediate destination name 

The short name that identifies the institution that 
receives the electronic check exchange file. 

Usage: Conditional. Shall be present, unless 
omitted under clearing arrangements. 

Position: 37 - 54 

Size: 18 

Type: A Alphabetic 

7.10 Immediate origin name 

The short name that identifies the institution that 
sends the electronic check exchange file. 

Usage: Conditional. Shall be present, unless 
omitted under certain clearing 
arrangements. 

Position: 55 - 72 

Size: 18 

Type: A Alphabetic 

7.11 File ID modifier 

A code that permits multiple electronic check 
exchange files, created on the same date and between 
the same institutions, to be distinguished one from 
another. 

Usage: Conditional. Shall be present, unless 
omitted under clearing arrangements. 

Position: 73 - 73 

Size: 1 

26 
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Type: AN Alphameric 
Defined 

Values: *A' through 'Z' 
4 CV through 4 9* 
7.12 Country code 

A code that identifies the country in which the payor 
bank is located. 

Usage: Conditional. Shall be present only if file 
consists of foreign items in US dollars. 



Position: 


74-75 


Size: 


2 


Type: 


A Alphabetic 


Defined 




Values: 


ISO specified values 


7.13 


User field 



A field used at the discretion of users of the standard. 

Usage: Conditional. Shall be present only under 
certain clearing arrangements. 

Position: 76 - 79 

Size: 4 

Type: ANS Alphameric/Special 
7.14 Reserved 

A field reserved for future use by the Accredited 
Standards Committee X9. 

Usage: Mandatory 

Position: 80-80 

Size: I 

Type: B Blank 
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8 Cash Letter Header Record (Type 10) 

The Cash Letter Header Record is mandatory and contains fourteen fields. The data in the fields are created by the 
ECE institution, which may or may not be the bank of Hist deposit. 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE 


1 


Record type 


M 


01-02 


2 


N 


2 


Collection type 
indicator 


M 


03-04 


2 


N 


3 


Final destination 
routing number 


M 


05-13 


9 


N 


4 


ECE institution routing 
number 


M 


14-22 


9 


N 


5 


Cash letter business 
date 


M 


23-30 


8 


N 


6 


Cash letter creation 
date 


M 


31-38 


8 


N 


7 


Cash letter creation 
time 


M 


39-42 


4 


N 


8 


Empty cash letter 
indicator 


M 


43-43 


1 


A 


9 


Truncation indicator 


C 


44-44 


1 


A 


10 


Cash letter ID 


C 


45-52 


8 


AN 


11 


Originator contact 
name 


c 


53-66 


14 


ANS 


12 


Originator contact 
phone number 


c 


67-76 


10 


N 


I 13 


User field 


c 


77-79 


3 


ANS 


I 14 


Reserved 


M 


80-80 


1 


B 
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8.1 Record type 

A code that identifies the type of record. 

Usage: Mandatory 

Position: 01 -02 

Size: 2 

Type: N Numeric 

Defined 

Values: * 10* Cash Letter Header 

8.2 Collection type indicator 

A code that identifies the type of cash letter and 
bundle. 

Usage: Mandatory 

Position: 03-04 

Size: 2 

Type: N Numeric 

Defined 

Values: '01* Forward Presentment 

*02* Forward Presentment-same-day 
settlement 

'03 * Return Request for truncated items 

*04' Return Notification 

*05 f Preliminary Return Information 

. 4 06" Second Preliminary Return 
Information 

8*3 Final destination routing number 

A number that identifies the institution that receives 
and processes the cash letter or the bundle. 

Usage: Mandatory 

Position: 05 - 1 3 

Size: 9 

Type: N Numeric 

Format: TTTTAAAAC, where: 

I ill Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 
C Check Digit 



8.4 ECE Institution routing number 

A number that identifies the institution that creates 
the cash letter header record. 

Usage: Mandatory 

Position: 14-22 

Size: 9 

Type: N Numeric 

Format: TTTTAAAAC, where: 

11 Federal Reserve Routing 
Symbol 

AAAA ABA Institution identifier 

C check digit 

8*5 Cash letter business date 

The year, month, and day that designates the business 
date of the cash letter. 

Usage: Mandatory 

Position: 23-30 

Size: 8 

Type: N Numeric 

Format: YYYYMMDD, where: 

YYYY year 

MM month 

DD day 

Defined 

Values: YYYY * 1 993 'through 4 9999' 

MM *01* through M 2' 

DD 'Or through '3 V 

8.6 Cash letter creation date 

The year, month, and day that the cash letter is 
created. 

Usage: Mandatory 

Position: 31 - 38 

Size: 8 

Type: N Numeric 

Format: YYYYMMDD, where: 

YYYY year 

MM month 

DD day 
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Defined 

Values: YYYY ' 1 993 ' through '9999' 
MM '01* through *12* 
DD 'OP through *3T 

8.7 Cash letter creation time 
The time the cash letter is created. 
Usage: Mandatory 
Position: 39-42 

Size: 4 

Type: N Numeric 

Format: hhmm, where: 

hh hour 

mm minute 

Defined 

Values: hh W through 4 23* 
mm * 00* through '59' 

8.8 Empty cash letter indicator 

A code which indicates whether the cash letter 
contains bundles of check detail records (type 25) or 
return records (type 3 1 ). 

Usage: Mandatory. 

Position: 43-43 

Size: 1 

Type: A Alphabetic 
Defined 

Values: *Y* Empty Cash Letter 

*N* Cash Letter contains items 

8.9 Truncation indicator 

A code that indicates if all of the items contained in 
the cash letter are truncated, regardless of the 
External Processing Code(s) found on the Check 
Detail Records (Type 25). 

Usage: Conditional. Shall be present if 

Collection Type Indicator value is '01' - 
Forward Presentment or * 02* - Forward 
Presentment - same-day settlement, and 
the Empty Cash Letter Indicator is not 
setto*Y\ 

Position: 44-44 

Size: 1 

Type: A Alphabetic 



Defined 

Values: C Y* Truncated 

*N* Not Truncated 

8.10 Cash letter ID 

A code that identifies the cash letter, assigned by the 
institution that creates the cash letter. 

Usage: Conditional. Shall be present, unless 
omitted under clearing arrangements. 

Position: 45-52 

Size: 8 

Type: AN Alphameric 

8. 1 1 Originator contact name 

A contact at the institution that creates the cash letter. 

Usage: Conditional. Shall be present, unless 
omitted under clearing arrangements. 

Position: 53 - 66 

Size: 14 

Type: ANS Alphameric/Special 

8. 1 2 Originator contact phone number 

The phone number of the contact at the institution 
that creates the cash letter. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 67 - 76 

Size: 10 

Type: N Numeric 

8.13 User field 

A field used at the discretion of users of the standard. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 77-79 

Size: 3 

Type: ANS Alphameric/Special 

8.14 Reserved 

A field reserved for future use by the Accredited 
Standards Committee X9. 



Usage: 
Position: 



Mandatory 
80-80 
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Size: 1 

Type: B Blank 



30 

Gotyiift* Anwkan rtaitonal Swnaana Institute 

PrwdW) tv W3 unew <c«ftM mIU» ANSI ScM to IMS SlinAnb Slot* FWum. 376913 

Nt> upreduaicr or ncMyluno pmnatsd wUiom Beans* bom MS Not tor ftesi)*0tf>7/2007 07:57:16 UST 



XKUUBU74t)ii4 



ANS X9.37-2001 ©ABA 
9 Bundle Header Record (Type 20) 

The Bundle Header Record is mandatory and contains twelve fields. The data in the fields are created by the BCE 
institution, which may or may not be the bank of first deposit. 



1 pipi n 


rlCLlS NMMC 




DncnrtAy 
rUolllUN 


one 

SIZE 


TYPE 


1 


Record type 


M 


01-02 


2 


N 


2 


Collection type 
indicator 


M 


03-04 


2 


N 


3 


Final destination 
routing number 


M 


05-13 


9 


N 


A 
*t 


ECE institution 
routing number 


M 


14 - 22 


9 


N I 


5 


Bundle business 
date 


M 


23-30 


8 


N ! 


6 


Bundle creation date 


M 


31-38 


8 


N I 




Bundle ID 


C 


39-48 


10 


AN | 


8 


Bundle sequence 
number 


C 


49-52 


4 


NB I 


9 


Cycle number 


C 


53-54 


2 


AN | 


10 


Return location 
routing number 


c 


55-63 


9 


N I 


11 


User field 


c 


64-65 


2 


ANS | 


12 


Reserved 


M 


66-80 


15 


B | 
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9.1 Record type 

A code that identifies the type of record. 
Usage: Mandatory 
Position: 01-02 
Size: 2 

Type: N Numeric 
Defined 

Values: *20' Bundle Header Record 

9.2 Collection type indicator 

A code that identifies the type of cash letter and 
bundle. 

Usage: Mandatory 

Position: 03 - 04 

Size: 2 

Type: N Numeric 
Defined 

Values: 4 0T Forward Presentment 

4 02' Forward Presentment- 
same day settlement 

"03* Return Request for truncated items 

'04* Return Notification 

'05* Preliminary Return Information 

4 06* Second Preliminary Return 
Information 

9J Final destination routing number 

A number that identifies the institution that receives 
and processes the cash letter or the bundle. 

Usage: Mandatory 

Position: 05-13 

Size: 9 

Type: N Numeric 

Format: TTTTAAAAC, where: 

I I I I Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 
C Check Digit 



9.4 ECE institution routing number 

A number that identifies the institution that creates 
the bundle header record. 

Usage: Mandatory 

Position: 14-22 

Size: 9 

Type: N Numeric 

Format: TTTTAAAAC, where 

TTTT Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 
C Check Digit 

9.5 Bundle business date 

The year, month, and day that designates the business 
date of the bundle. 

Usage: Mandatory 

Position: 23-30 

Size: 8 

Type: N Numeric 

Format: YYYYMMDD, where: 

YYYY year 

MM month 

DD day 

Defined 

Values: YYYY M 993' through '9999 ' 
MM 4 01* through *I2* 
DD *01* through *3T 
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9.6 Bundle creation date 

The year, month, and day that the bundle is created. 
Usage: Mandatory 
Position: 31-38 
Size: 8 

Type: N Numeric 
Format: YYYYMMDD, where: 

YYYY year 

MM month 

DD day 

Defined 

Values: YYYY * 1993' through '9999' 
MM *0l' through '12' 
DD 'OP through '3 V 

9.7 Bundle ID 

A number that identifies the bundle, assigned by the 
institution that creates the bundle. 

Usage: Conditional. Shall be present, unless 
omitted under clearing arrangements. 

Position: 39-48 
Size: 10 

Type: AN Alphameric 

9.8 Bundle sequence number 

A number assigned by the institution that creates the 
bundle. Usually denotes the relative position of the 
bundle within the cash letter. 

Usage: Conditional. Shall be present, unless 
omitted under clearing arrangements. 

Position: 49-52 

Size: 4 

Type: NB Numericblank 

9.9 Cycle number 

A code assigned by the institution that creates the 
bundle. Denotes the cycle under which the bundle is 
created. 

-Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 53 - 54 

Size: 2 



Type: AN Alphameric 

9.10 Return location routing number 

A number specified by the Institution that creates the 
bundle, indicating the location to which preliminary 
return information, return notifications and return 
requests should be sent. 

Usage: Conditional. Shall be present if 

collection type indicator value is *01 * - 
Forward Presentment or 4 02' - Forward 
Presentment-same day settlement, 
unless omitted under clearing 
arrangements. 

Position: 55 - 63 

Size: 9 

Type: N Numeric 

Format: TTTTAAAAC. where: 

TTTT Federal Reserve Routing 
Symbol 

AAA A ABA Institution Identifier 
C check digit 

9.11 User field 

A field used at the discretion of users of the standard. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 64-65 

Size: 2 

Type: ANS Alphameric/Special 

9.12 Reserved 

A field reserved for future use by the Accredited 
Standards Committee X9. 

Usage: Mandatory 

Position: 66-80 

Size: 15 

Type: B Blank 
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10 Check Detail Record (Type 25) 

The Check Detail Record is conditional and contains sixteen fields. It shall be present in a bundle designated as 
forward presentment with a collection type indicator of 4 0r or *02\ One check detail record shall be sent for each 
check. The data in fields 2 through 7 are read from the check MICR line; the order of these fields is the order in 
which they appear on the check. 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE [ 


1 


Record type 


M 


01 -02 


2 


N j 


2 


Auxiliary On Us 


C 


03-17 


15 


NBSM | 




External processing 
code 


C 


18-18 


1 


NBSM | 


4 


Pavor bank rout in □ 

number 


M 


19-26 


8 


N 


5 


Paunr hank mi it inn 

number check digit 


c 


27-27 


1 


NBSM 


6 


On Us 


c 


28-47 


20 


NBSMOS 


7 


Item amount 


M 


48-57 


10 


N 


8 


ECE institution item 
sequence number 


M 


58-72 


15 


NB 


9 


Documentation type 
indicator 


M 


73-73 


1 


NB 


10 


Return acceptance 
indicator 


M 


74-74 


1 


AN 


11 


MICR valid indicator 


C 


75-75 


1 


NB 


12 


BFD indicator 


M 


76-76 


1 


A 


13 


Check detail record 
addendum count 


M 


77-77 


1 


N 


14 


On Us format 
indicator 


M 


78-78 


1 


N 


15 


User field 


C 


79-79 


1 


ANS 


16 


Reserved 


M 


80-80 


1 


B 
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1 0.1 Record type 

A code that identifies the type of record. 
Usage: Mandatory 
Position: 01-02 
Size: 2 

Type: N Numeric 
Defined 

Values: *25' Check Detail Record 

10.2 Auxiliary On Us 

A code used on commercial checks at the discretion 
of the payor bank. 

Usage: Conditional. Shalt be present if on the 
M1CR line. 

Position: 03-17 

Size: 15 

Type: NBSM Numericblank; 

special MICR 

10 J External processing code 

A code used for special purposes as authorized by the 
Accredited Standards Committee X9. Also known as 
Position 44. 

Usage: Conditional. Shall be present if on the 
MICR line. 

Position: 18-18 

Size: 1 

Type: NBSM Numericblank/ 

special MICR 

10.4 Payor bank routing number 

A number that identifies the institution by or through 
which the item is payable. 

Usage: Mandatory 

Position: 19-26 

Size: 8 

Type: N Numeric 

Format: I 111 AAA A, where: 

I ill Federal Reserve Routing 
Symbol 

A AAA ABA Institution Identifier 



10.5 Payor bank routing number check digit 

A digit used with a modular check digit routine to 
validate the Routing Number. 

Usage: Conditional. Shall be present if on the 
MICR line. 

Position: 27-27 

Size: I 

Type: NBSM Numericblank/Specia! MICR 
Format: C Check Digit 

10.6 On Us 

Data specified by the payor bank. On Us data usually 
consists of the payor's account number, a serial 
number or transaction code, or both. 

Usage: Conditional. Shall be present if 

truncation indicator value is *Y\ If 
truncation indicator value is 4 N\ shall 
be present unless omitted under clearing 
arrangements. 

Position: 28-47 



Size: 



20 



Type: NBSMOS Numericblank/special 
MICR On us 

10.7 Item amount 

The US dollar value of the check. 

Usage: Mandatory 

Position: 48-57 

Size: 10 

Type: N Numeric 

1 0.8 ECE Institution Item sequence number 

A number assigned by the institution that creates the 
check detail record. 

Usage: Mandatory 

Position: 58 - 72 

Size: 15 

Type: NB Numericblank 



10.9 Documentation type indicator 

A code that indicates the type of documentation that 
supports the check detail record. 

Usage: Mandatory 

Position: 73 -73 



CooyrioM Amrtaft Kntorat &**canH bafeiut 

Pr»*W Of MS urtJ* GCCRM wtfl ANS 

Mo retwxJucwo or inwtog pp n-jued Mho* Icvim trem MS 



SOU toWS SundrC* Store Pwtfma. 37691 J 
Not tar ft«ult.au)7a007 07*7:46 MST 



35 



XP008074624 



ANS/X937-2001 



©ABA 



Size: 

Type: 

Defined 
Values: 



1 

AN Alphameric 



'A* Paper to follow 

*B* Paper to follow; 
microfilm archive available 

*C* Paper to follow; 
image archive available 

*D* Paper to follow; image archive 
transmission available 

*E* Paper to follow; microfilm and 
image archive available 

*F Paper to follow, microfilm and 
image archive available, image archive 
transmission available. 

*G* Image to follow 

'H* Image to follow; microfilm archive 
available 

T Image to follow; image archive 
available 

4 J* Image to follow; image archive 
transmission available 

4 K' Image to follow; microfilm and 
image archive available 

4 L* Image to follow; microfilm and 
image archive available, image archive 
transmission available 

*M* Paper and image to follow 

*N' Paper and image to follow; 
microfilm archive available 

*()' Paper and image to follow; image 
archive available 

*P* Paper and image to follow; image 
archive transmission available 

*Q* Paper and image to follow; 
microfilm and image archive available 

4 R* Paper and image to follow; 
microfilm and image archive available, 
image archive transmission available 

*S' Truncation; microfilm archive 
available 

*T* Truncation; image archive available 

'IT Truncation; image archive 
transmission available 



4 V* Truncation; microfilm and image 
archive available 

'W* Truncation; microfilm and image 
archive available, image archive 
transmission available 

'X' All electronic check to follow 

* Y* Truncation; all electronic check 
archive available 

10.10 Return acceptance Indicator 

A code that indicates whether the institution that 
creates the check detail record will or will not accept 
electronic return information. 

Usage: Mandatory 

Position: 74 - 74 



Size: 

Type: 

Defined 
Values: 



I 

AN 



Alphameric 



1 1 Will accept preliminary return 

n formation, return request for truncated 

terns, and return notifications 

2' Will accept preliminary return 
information and return request for 
truncated items 

'3* Will accept preliminary return 
information and return notifications 

1 4* Will accept return request for 
truncated items and return notifications 

4 5* Will accept preliminary return 
information only 

*6' Will accept return request for 
truncated items only 

'7' Will accept return notification only 

"8* Will not accept electronic return 
information 

* A* Will accept preliminary return 
information, return request for truncated 
items, return notifications and second 
preliminary return information. 

*B* Will accept preliminary return 
information, return request for truncated 
items and second preliminary return 
information. 

l C* Will accept preliminary return 
information, return notifications and 
second preliminary return information. 
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*D' Will accept return request for 
truncated items, return notifications and 
second preliminary return information. 

4 E* Will accept preliminary return 
information and second preliminary 
return information. 

4 F* Will accept return request for 
truncated items, and second preliminary 
return information. 

4 G' Will accept return notifications and 
second preliminary return information. 

'H* Will accept second preliminary 
return information only. 



10.11 M1CR valid indicator 

A code that indicates whether any character in the 
Auxiliary On Us field, the External Processing Code 
field, the Payor Bank Routing Number field, the 
Payor Bank Routing Number Check Digit field, the 
On Us field, or the Item Amount field, is unreadable; 
or, the On Us field is missing from the Check Detail 
Record. 

Usage: Conditional. Shalt be present only under 
clearing arrangements. 

Position: 75-75 

Size: I 

Type: NB Numeric blank 
Defined 

Values: * 1 * Good read 

4 2' Good read, missing field 

*3* Read error encountered 

4 4' Missing field and read error 
encountered 

10.12 BFD Indicator 

A code that indicates whether the ECE institution 
indicated on the bundle header record (type 20) is the 
bank of first deposit (BFD). 

Usage: Mandatory 

Position: 76-76 



Size: 
Type: 



I 

A 



Alphabetic 



4 U* ECE institution relationship to BFD 
is undetermined 

10.13 Check detail record addendum count 

The number of check detail record addenda to follow. 
Usage: Mandatory 
Position: 77-77 
Size: I 

Type: N Numeric 
Defined 

Values: 4 0' no addenda 

4 1 * one addendum to follow 
4 2* two addenda to follow 

10.14 On Us format indicator 

A code that indicates how the On Us field is 
formatted. 

Usage: Mandatory 
Position: 78 - 78 
Size: I 

Type: N Numeric 
Defined 

Values: * I * Standard Format 

4 2* Interim fixed format 

10.15 User field 

A field used at the discretion of users of the standard. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 79 Values: 79 

Size: t 

Type: ANS Alphameric/Special 

10.16 Reserved 

A field reserved for future use by the Accredited 
Standards Committee X9. 

Usage: Mandatory 

Position: 80 -: 80 

Size: 1 

Type: B Blank 



Defined 

Values: 4 Y* ECE institution is BFD 

*N* ECE institution is not BFD 
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1 1 Check Detail Addendum A Record (Type 26) 

The Check Detail Addendum A Record is conditional and contains eight fields. It shall be present unless omitted under 
clearing arrangements; the record is created by the ECE institution, which may or may not be the bank of first deposit. 
It is one of two addenda available for use with the Check Detail Record (Type 25). 



FIELD 


PIcLU NAME 


UoAut 


poQiTinu 
ruoi i lun 




TYPE 


1 


RcmwtI tvno 
rxuwiu ly yjxj 


M 


01 - 02 


2 


N 


2 


Correcting institution 
routing number 


C 


03-11 


9 




3 


Bank of First Deposit 
(BFD) routing number 


C 


12-20 


9 


NB 


4 


BFD business 
(endorsement) date 


c 


21 -28 


8 


N 


5 


BFD item sequence 
number 


c 


29-43 


15 


NB. | 




Deposit account number 
at BFD 


c 


44-61 


18 


ANS I 


7 


BFD deposit branch 


c 


62-66 


5 


ANS 


8 


Payee name 


c 


67-80 


14 


ANS 
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11.1 Record type 

A code that identifies the type of record. 
Usage: Mandatory 
Position: 01-02 
Size: 2 

Type: N Numeric 
Defined 

Values: '26* Check Detail 

Addendum A Record 

1 1.2 Correcting institution routing number 

A number which identifies the ECE institution that 
corrects any data on the Check Detail Record (type 
25). 

Usage: Conditional. Shall be present if any data 
on the Check Detail Record (type 25) 
has been corrected. 

Position: 03 - 11 

Size: 9 

Type: N Numeric 

Format: TTTTAAAAC, where: 

1111 Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 

C Check Digit 

1 1-3 Bank of First Deposit (BFD) 
routing number 

A number that identifies the bank of first deposit. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 12-20 

Size: 9 

Type: NB Numericblank 

Format: TTTTAAAAC, where: 

TTTT Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 
C Check Digit 



1 1.4 BFD business (endorsement) date 

The year, month, and day in the endorsement that 
designates the business date at the bank of first 
deposit. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 21-28 

Size: 8 

Type: N Numeric 
Format: Y Y Y YM MDD, where : 

YYYY year 

MM month 

DD day 

Defined 

Values: YYYY M 993' through * 9999' 
MM *01* through M2* 
DD *0r through *31' 

1 1.5 BFD item sequence number 

A number that identifies the item at the bank of first 
deposit. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 29-43 

Size: 15 

Type: NB Numericblank 

1 1 .6 Deposit account number at BFD 

A number that identifies the depository account at the 
bank of first deposit. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 44-61 

Size: 18 

Type: ANS Alphameric/Special 
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11.7 BFD deposit branch 

A code that identifies the branch at the bank of first 
deposit. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 62 - 66 

Size: 5 

Type: ANS Alphameric/Special 

11.8 Payee Dame 

The name of the payee from the check. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 67-80 

Size: 14 

Type: ANS Alphameric/Special 
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1 2 Check Detail Addendum B Record (Type 27) 

The Check Detail Addendum B Record is conditional and contains five fields. It shall be present only under clearing 
arrangements. It is one of two addenda available for use with the Check Detail Record (Type 25). 



FIELD 

1 


FIELDNAME 


USAGE 


POSITION 


SIZE 


II 

TYPE 


1 


Record type 


M 


01 -02 


2 


N 


2 


Microfilm archive 
sequence number 


C 


03-17 


15 


NB 


3 


Image archive 
sequence number 


C 


18-41 


24 


NB 


4 


User field 


c 


42-65 


24 


ANS 


5 


Reserved 


M 


66-80 


15 


B 
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12.J Record type 

A code that identifies the type of record. 



Usage: 

Position: 

Size: 

Type: 

Defined 
Values: 



Mandatory 
01 -02 
2 

N Numeric 

*27' Check Detail Addendum B 
Record 



12.2 Microfilm archive sequence number 

A number that identifies the item in the microfilm 
archive system; it may be different than the ECE Item 
Sequence Number and the Image Archive Sequence 
Number. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 03-17 

Size: 15 

Type : N B Numericbtank 

12 J Image archive sequence number 

. A number that identifies the item in the image 
archive system; it may be different than the ECE Item 
Sequence Number and the microfilm Archive 
Sequence Number. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 18-41 

Size: 24 

Type: NB Numericblank 

12.4 User Field 

A field used at the discretion of users of the standard. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 42-65 

Size: 24 

Type: ANS Alphameric/Special 



Usage: Mandatory 

Position: 66-80 

Size: 15 

Type: B Blank 



12.5 



Reserved 



A field reserved for future use by the Accredited 
Standards Committee X9. 
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13 Return Record (Type 31) 

The Return Record is conditional, and contains eleven fields; it shall be present in a bundle designated as return 
notification with a collection type indicator of *03* return Request for Truncated Items, *04* Return Notification, 
*05 f Preliminary Return Information, or '06* Second Preliminary Return Information. One return record shall be 
sent for each electronic return. The record is created by the payor bank or the returning ECE institution. 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 




1 


Record tvoa 


M 

IVI 


Ul — 


2 


N 


2 


Payor bank routing 
number 


M 


03-10 


8 


N 


3 


Payor bank routing 
number check digit 


C 


11-11 


1 


NBSM 


4 


On Us return record 


C 


12-31 


20 


NBSMOS 




Item Amount 


M 


32-41 


10 


N 


: 


Return reason 


M 


42-42 


1 


AN 


7 


Return record 
addendum count 


M 


43-43 


1 


N 


8 


Forward bundle 
creation date 


C 


44-51 


8 


N 


9 


ECE institution 
forward Hem 
sequence number 


C 


52-66 


15 


NB 


10 


Payor account name 


c 


67-79 


13 


ANS 




User field 


c 


80-80 


1 


ANS B 
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13.1 Record type 

A code that identifies the type of record. 
Usage: Mandatory 
Position: 01-02 
Size: 2 

Type: N Numeric 

Defined 

Values: *3 1 ' Return Record 

13.2 Payor bank routing number 

A number that identifies the institution by or through 
which the item is payable. 

Usage: Mandatory 

Position: 03-10 

Size: 8 

Type: N Numeric 

Format: TTTTAAAA, where: 

in 1 Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 

_ JL33 Pa yor bank routing number check di git 

A digit used with a modular check digit routine to 
validate the routing number. 

Usage: Conditional. Shall be present if on the 
MICR line. 

Position: 11-11 

Size: I 

Type: NBSM Numbericblank/special MICR 

Format: C Check Digit 

13.4 On Us return record 

The On Us data from the incoming check detail 
record (type 25). On Us data usually consists of the 
payor's account number, a serial number or 
transaction code, or both. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 12-31 

Size: 20 

Type: NBSMOS Numeric blank/Special 

MICR On us 



13.5 Item amount 

The US dollar value of the check. 

Usage: Mandatory 

Position: 32-41 

Size: 10 

Type: N Numeric 

13.6 Return reason 

A code which indicates the reason for non-payment. 
Usage: Mandatory 
Position: 42 - 42 
Size: 1 

Type: AN Alphameric 

Defined 

Values: A* NSF - Not Sufficient 
Funds 

*B* UCF - Uncollected Funds Hold 

*C* Stop Payment 

*D' Closed Account 

'E* UTLA - Unable to Locate Account 

.p.? Frozen/Blocked-Account - 

'G' Stale Dated 

*rT Post Dated 

T Endorsement Missing 

T Endorsement Irregular 

4 K' Signature Missing 

*L* Signature Irregular 

4 M* Non-Cash Item 

'N' Altered/Fake Item 

'O' Mutilated Item 

'P' Item Exceeds Dollar Limit 

'Q* Not Authorized 

4 R* Branch/ Account Sold 

*S' Refer to Maker 

*T* Stop Payment Suspect 

13.7 Return record addendum count 

The number of return record addenda to follow. 
Usage: Mandatory 
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Position: 

Size: 

Type: 

Defined 
Values: 



43-43 
I 

N Numeric 

1 0' No Addenda 

* 1 ' One Addendum to Follow 

*2* Two Addenda to Follow 

4 3* Three Addenda to Follow 

13.8 Forward bundle creation date 

For electronic check exchange items, the year, 
month, and day that the forward bundle was created. 
For items presented in paper cash tetters, the year, 
month, and day that the cash letter was created. 

Usage: Conditional. Shall be present if items 

are presented electronically. If items are 
presented through a paper cash letter 
shall be present if available. 

Position: 44-51 

Size: 8 

Type: N Numeric 
Format: YYYYMMDD, where: 

YYYY year 

MM month 

DD day 



Defined 
Values: 



13.9 



YYYY '1993* through '9999' 

MM *0r through * 1 2* 

DD *0r through 4 3T 

ECE Institution forward Item sequence 
number 



A number which identifies the item. If the item is 
presented electronically, the number is assigned by 
the ECE institution; if the item is presented through a 
paper cash letter, the number is assigned by the bank 
of first deposit. 

Usage: Conditional. Shall be present if items 

are presented electronically. If items are 
presented through a paper cash letter, 
shall be present if available. 

Position: 52 - 66 

Size: 15 

Type: NB Numericblank 



13.10 Payor account name 

The account name from payor bank records. 

Usage: Conditional. Shall be present only under 
clearing arrangements 

Position: 67 -79 

Size: 13 

Type: ANS Alphameric/Special 

13.11 User field 

A Held used at the discretion of users of the standard. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 80-80 

Size: 1 

Type: ANS Alphameric/Special 
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1 4 Return Addendum A Record (Type 32) 

The Return Addendum A Record is conditional and contains thirteen fields. It shall be present unless omitted under 
clearing arrangements. It is one of three addenda available for use with the Return Record (Type 31 ). 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE | 


1 


Record type 


M 


01-02 


2 


N 


2 


Bank of first deposit 
(BFD) routing number 


C 


03-11 


9 


NB 


3 


BFD business 
(endorsement) date 
confidence indicator 


C 


12-12 


1 


AN 


4 


BFD business 
(endorsement) date 




IO — £v 


8 


N 


5 


BFD item sequence 
number confidence 
indicator 


C 


21-21 


1 


AN 


6 


BFD item sequence 
number 


c 


22-36 


15 


NB 1 


7 


Deposit account number 
at BFD confidence 
indicator 


c 


37-37 


1 


AN 


8 


Deposit account number 
at BFD 


c 


38-55 


18 


ANS 


9 


BFD deposit branch 
confidence indicator 


c 


56-56 


1 


AN 


10 


BFD deposit branch 


c 


57-61 


5 


ANS 


11 


Payee name confidence 
indicator 


c 


62-62 


1 


AN 


12 


Payee name 


c 


63-76 


14 


ANS 1 


13 


Reserved 


M 


77-80 


4 


8 | 
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14.1 Record type 

A code that identifies the type of record. 
Usage: Mandatory 
Position: 01-02 
Size: 2 

Type: N Numeric 
Defined 

Values: *32* Return Addendum A 
Record 

14.2 Bank of first deposit (BFD) routing 

number 

A number that identifies the bank of first deposit. 

Usage: Conditional. Shalt be present if 

available, unless omitted under clearing 
arrangements. 

Position 03-11 

Size: 9 

Type: NB Numericblank 

Format: TTTTAAAAC, where: 

nn Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 

C Check Digit 

14 J BFD business (endorsement) date 
confidence Indicator 

A code that indicates whether or not the paying bank 
is sure of the accuracy of the data. 

Usage: Conditional. Shall be present if the 
following field is present. 



Position: 


12- 


12 


Size: 


1 




Type: 


AN 


Alphameric 


Defined 


Y' 


sure of content 


Values: 


'N* 


content in doubt 



Blank following field not provided 

14.4 BFD business (endorsement) date 

The year, month, and day in the endorsement that 
designates the business date at the bank of first 
deposit. 



©ABA 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 13-20 

Size: 8 

Type: N Numeric 

Format: YYYYMMDD, where: 

YYYY year 

MM month 

DD day 

Defined 

Values: YYYY * 1993* through * 9999' 

MM *0T through M2 1 

DD 'Or through *3T 

14.5 BFD Item sequence number confidence 

indicator 

A code that indicates whether or not the paying bank 
is sure of the accuracy of the data. 

Usage: Conditional. Shall be present if the 
following field is present. 

Position 21-21 

Size: 1 

Type: AN Alphameric 
Defined 

Values: *Y' sure of content 

*N* content in doubt 

Blank following field not provided 

14.6 BFD item sequence number 

The number that identifies the item at the bank of 
first deposit. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 22 - 36 

Size: 15 

Type: NB Numericblank 

1 4.7 Deposit account number at BFD 

confidence Indicator 

A code that indicates whether or not the paying bank 
is sure of the accuracy of the data. 
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Usage: Conditional. Shalt be present if the 
following Held is present. 

Position: 37 - 37 

Size: 1 

Type: AN Alphameric 
Defined 

Values T* sure of content 
*N* content in doubt 
Blank following field not provided 

14.8 Deposit account number at BFD 

A number that identifies the depository account at the 
bank of first deposit. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 38-55 

Size: 18 

Type: ANS Alphameric/Special 

14.9 BFD deposit branch confidence indicator 

A code that indicates whether or not the paying bank 
is sure of the accuracy of the data. 

Usage: Conditional. Shall be present if the 
following field is present. 

Position: 56-56 

Size: 1 

Type : AN Alphameric 
Defined 

Values: 'Y' sure of content 
'N* content in doubt 
Blank following field not provided 

14.10 BFD deposit branch 

A code that identifies the branch at the bank of first 
deposit. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 57-61 



14.1 1 Payee name confidence indicator 

A code that indicates whether or not the paying bank 
is sure of the accuracy of the data. 

Usage: Conditional. Shall be present if the 
following field is present 

Position: 62-62 

Size: 1 

Type: AN Alphameric 
Defined 

Values: *Y T sure of content 
4 N* content in doubt 
Blank following field not provided 

14.12 Payee name 

The name of payee from the check. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 63 - 76 

Length: 14 

Type: ANS Alphameric/Special 

14.13 Reserved 

A field reserved for future use by the Accredited 
Standards Committee X9, 

Usage: Mandatory 

Position: 77-80 

Length: 4 

Type: B Blank 



Size: 
Type: 



ANS Alphameric/Special 
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1 5 Return Addendum B Record (Type 33) 

The Return Addendum B Record is conditional and contains six fields. It shall be present unless omitted under clearing 
arrangements. It is one of three addenda available for use with the Return Record (Type 31). 



| FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE 


j 1 


Record type 


M 


01-02 


2 


N 


2 


Payor bank name 


C 


03-20 


18 


A 


3 


Payor account 
name extension 


C 


21-40 


20 


ANS 


4 


Auxiliary On Us 


C 


41-55 


15 


NBSM 


5 


External 

processing code 


C 


56-56 


1 


NBSM 


6 


Reserved 


M 


57-80 


24 


B 
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15.1 Record type 

A code that identifies the type of record. 
Usage: Mandatory 
01-02 
2 

N Numeric 



Position: 

Size: 

Type: 

Defined 
Values: 

15.2 



'33* Return Addendum B Record 
Payor bank name 



The short name of the institution by or through which 
the item is payable. 

Usage: Conditional. Shall be present unless 
omitted under clearing arrangements 

Position: 03 - 20 

Size: 18 

Type: A Alphabetic 

I S3 Payor account name extension 

An extension of the account name from payor bank 
records. 

Usage: Conditional. Shall be present if 

necessary to complete the payor account 
name, unless omitted under clearing 
arrangements. 

Position: 21-40 

Size: 20 

Type: ANS Alphameric/Special 



Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 56-56 

Size: I 

Type: NBSM Numericblank/Special MICR 
15.6 Reserved 

A field reserved for future use by the Accredited 
Standards Committee X9. 

Usage: Mandatory 

Position: 57-80 

Size: 24 

Type: B Blank 



15.4 Auxiliary On Us 

A code used on commercial checks at the discretion 
of the payor bank. 

Usage: Conditional. Shall be present if 

available, unless omitted under clearing 
arrangements. 

Position: 41-55 

Size: 15 

Type: NBSM Numericblank/Special MICR 

1 5.5 External processing code 

A code used for special purposes as authorized by the 
Accredited Standards Committee X9. Also known as 
Position 44. 
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16 Return Addendum C Record (Type 34) 

The Return Addendum C Record is conditional and contains five fields. It shall be present only under clearing 
arrangements. It is one of three addenda available for use with the Return Record (Type 3 1 ). 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE 


1 


Record type 


M 


01-02 


2 


N 


2 


Forward microfilm 
archive sequence 
number 


C 


03-17 


15 


NB 


3 


Forward image archive 
sequence number 


c 


18-41 


24 


NB 


4 


User field 


c 


42-65 


24 


ANS 


5 


Reserved 


M 


66-80 


15 


B 
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16.1 Record type 

A code thai identifies the type of record. 



16.5 



Reserved 



Usage: 

Position: 

Size: 

Type: 

Defined 
Values: 



Mandatory 

01-02 

2 

N Numeric 

*34* Return Addendum C 
Record 



16.2 Forward microfilm sequence number 

A number that identifies the item in the Microfilm 
Archive System, taken from the incoming Check 
Detail Addendum B record; it may be different than 
the ECE Institution Item Sequence Number and the 
Image Archive Sequence Number. 

Usage: Conditional. Shall be present only under 
clearing arrangements 

Position: 03-17 

Size: 15 

Type: NB Numericblank 

16.3 Forward image archive sequence number 

A number that identifies the item in the image 
archive system, taken from the incoming Check 
Detail Addendum B record; it may be different than 
the ECE Institution Forward Item Sequence Number 
and the Forward Microfilm Archive Sequence 
Number. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 18-41 

Size: 24 

Type: NB Numericblank 

16.4 User field 

A field used at the discretion of users of the standard. 
Usage: 



Conditional. Shall be present only under 
clearing arrangements. 

Position: 42-65 

Size: 24 

Type: ANS Alphameric/Special 



A field reserved for future use by the Accredited 
Standards Committee X9. 



Usage: 
Position: 
Size: 
Type: 



Mandatory 

66-80 

15 



B 



Blank 
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1 7 Bundle Control Record (Type 70) 

The Bundle Control Record is mandatory, and contains six fields. There shall be one Bundle Control Record 
corresponding to each Bundle Header Record (Type 20). The data in the fields are generated by the ECE institution 
that created the corresponding Bundle Header Record. 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE 


1 


Record type 


M 


01-02 


2 


N 


2 


Hems within bundle 
count 


M 


03-06 


4 


N 


3 


Bundle total amount 


M 


07-18 


12 


N 


4 


MICR valid total amount 


C 


19-30 


12 


N 


5 


User field 


C 


31-78 


48 


ANS 


6 


Reserved 


M 


79-80 


2 


B 
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17.1 Record type 

A code that identifies the type of record. 



Usage: 

Position: 

Size: 

Type: 

Defined 
Values: 



Mandatory 

01-02 

2 

N Numeric 



'70' Bundle Control Record 

17.2 Items within bundle count 

The total number of items sent within a bundle, all 
check detail records (type 25) or all return records 
(type 31). 

Usage: Mandatory 
Position: 03 - 06 
Size: 4 

Type: N Numeric 

17.3 Bundle total amount 

The total US dollar value of the items within the 
bundle, all check detail records (type 25) or all return 
records (type 31). 



Usage: 
Position: 
Size: 
Type: 



Mandatory 
07- 18 
12 

N Numeric 



17.4 M1CR valid total amount 

The total US dollar value of all check detail records 
(type 25) which contain the value T in the M1CR 
valid indicator field. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 19-30 

Size: 12 

Type: N Numeric 

17.5 User field 

A field used at the discretion of users of the standard. 
Usage: 



Position: 
Size: 



Conditional. Shall be present only under 
clearing arrangements. 

31-78 

48 



Type: 
17.6 



ANS 
Reserved 



Alphameric/Special 



A field reserved for future use by the Accredited 
Standards Committee X9. 

Usage: Mandatory 

Position: 79-80 

Size: 2 

Type: B Blank 
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1 8 Box Summary Record (Type 75) 

The Box Summary Record is conditional and contains seven fields. It shall be present only under clearinc 
arrangements. It is generated by the ECE institution, and contains data related to box processing. There shall be one 
Box Summary Record per box (box of bundles). Cash letters that have Box Summary Records and those that do not 
may be commingled within a single ECE file. ' 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE 




Record type 


M 


01 -02 


2 


N 




Final destination 
routing number 


M 


03-11 


9 


N 


3 


Box sequence 
number 


M 


12-14 


3 


N 


4 


Box bundle count 


M 


15-18 


4 


N 


5 


Box number ID 


M 


19-26 


8 


N 


6 


Box total amount 


M 


27-40 


14 


N 


7 


Reserved 


M 


41-80 


40 


B 
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18.1 Record type 

A code that identifies the type of record. 
Usage: Mandatory 
Position: 01-02 
Size: 2 

Type: N Numeric 

Defined 

Values: '75' Box Summary Record 

18.2 Final destination routing number 

A number that identifies the institution that receives 
and processes the cash letter or the bundle. 

Usage: Mandatory 

Position: 03 - 1 1 

Size: 9 

Type: N Numeric 

Format: TTTTAAAAC, where: 

TTTT Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 

C Check Digit 

183 Box sequence number 

A number assigned by the institution that creates the 
box. Usually denotes the relative position of the box 
within the cash letter. 

Usage: Mandatory 

Position: 12-14 

Size: 3 

Type: N Numeric 

18.4 Box bundle count 

The total number of bundles in the box. 
Usage: Mandatory 
Position: 15-18 
Size: 4 

Type: N Numeric 

18.5 Box number ID 

A code that identifies the box, assigned by the 
institution that creates the box. 



Position: 19-26 
Size: 8 

Type: N Numeric 

18.6 Box total amount 

The total US dollar value of the bundles in the box. 

Usage: Mandatory 

Position: 27-40 

Size: 14 

Type: N Numeric 

18.7 Reserved 

A field reserved for future use by the Accredited 
Standards Committee X9. 

U sage : M andatory 

Position: 41-80 

Size: 40 

Type: B Blank 



Usage: 



Mandatory 
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1 9 Routing Number Summary Record (Type 85) 

The Routing Number Summary Record is conditional and contains five fields. It shall be present only under clearine 
arrangements. When used, there is one record for each payor bank Routing Number represent in the cas TleVte r * 
The data is generated by the ECE institution. 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE 


1 


Record type 


M 


01-02 


2 


N 


2 


Routing number within 
cash tetter 


M 


03-11 


9 


NB 


3 


Routing number total 
amount 


M 


12-25 


14 


N 


4 


Routing number items 
count 


M 


26-31 


6 


N 


I 5 


Reserved 


M 


32-80 


49 


B 
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19.1 Record type 

A code that identifies the type of record. 



Usage: 

Position: 

Size: 

Type: 

Defined 
Values: 



Mandatory 
01 -02 
2 

N Numeric 

*85' Routing Number Summary 
Record 



19.2 Routing number within cash letter 

A number that identifies a given payor bank within a 
cash letter containing one or more payor banks. 

Usage: Mandatory 

Position: 03 - 1 1 

Size: 9 

Type: NB Numericblank 

Format: TTTTAAAAC, where: 

TTTT Federal Reserve Routing 
Symbol 

AAAA ABA Institution Identifier 

C Check Digit 

19 J Routing number total amount 

The total US dollar value for all check detail records 
(type 25) associated with the payor bank routing 
number designated in the field "Routing Number 
within Cash Letter". 

Usage: Mandatory 

Position: 12-25 

Size: 14 

Type: N Numeric 

19.4 Routing number items count 

The total number of all check detail records (type 25) 
associated with the payor bank routing number 
designated in the field "Routing Number within Cash 
Letter". 



Usage: 
Position: 
Size: 
Type: 



Mandatory 

26-31 

6 

N Numeric 



19.5 Reserved 

A field reserved for future use by the Accredited 
Standards Committe X9. 

Usage: Mandatory 

Position: 32 - 80 

Size: 49 

Type: B Blank 
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20 Cash Letter Control Record (Type 90) 

The Cash teller Control Record is mandatory and contains eight fields. There must be one cash letter control record 
corresponding to each cash letter header record (type 10). The data in the fields are generated by the ECE institution 
that created the corresponding cash letter header record. 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE 


1 


Record type 


M 


01-02 


2 


N 


2 


Bundle count 


M 


03-08 


6 


N | 


3 


Items within cash letter 
count 


M 


09- 16 


8 


N fl 


4 


Cash letter total amount 


M 


17-30 


14 


N 


5 


Final destination name 


C 


31-48 


18 


A 


• 


ECE institution name 


C 


49-66 


18 


A 


7 


Settlement date 


c 


67-74 


8 


N 


8 


Reserved 


M 


75-80 


6 


B 
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20.1 Record type 

A code that identifies the type of record. 
Usage: Mandatory 
Position: 01-02 
Size: 2 

Type: N Numeric 

Defined 

Values: '90' Cash Letter Control Record 

20.2 Bundle count 

The total number of bundles within the cash letter. 
Usage: Mandatory 
Position: 03 - 08 
Size: 6 

Type: N Numeric 

20-3 Items within cash letter count 

The total number of items sent within the cash letter, 
all check detail records (type 25) or all return records 
(type 31). 

Usage: Mandatory 
Position: 09-16 
Size. 8 

Type: N Numeric 

20.4 Cash letter total amount 

The total US dollar value of the cash letter, all check 
detail records (type 25) or all return records (type 
31). 

Usage: Mandatory 

Position: 17-30 

Size: 14 

Type: N Numeric 

20.5 Final destination name 

The short name of the institution that receives and 
processes the cash letter. 

Usage: Conditional. Shall be present* unless 
omitted under clearing arrangements. 

Position: 31-48 

Size: 18 

Type: A Alphabetic 



20.6 ECE Institution name 

The short name of the institution that creates the Cash 
Letter Control Record (Type 90). 

Usage: Conditional. Shall be present, unless 
omitted under clearing arrangments. 

Position: 49 - 66 

Size: 18 

Type: A Alphabetic 

20.7 Settlement date 

The year, month, and day that the institution that 
creates the cash letter expects settlement. 

Usage: Conditional. Shall be present only under 
clearing arrangements. 

Position: 67 - 74 

Size: 8 

Type: N Numeric 

Format: YYYYMMDD, where: 

YYYY year 

MM month 

DD day 

Defined 

Values: YYYY M993' through *9999' 

MM '0T through 4 12' 

DD *0r through *3T 
20.8 Reserved 

A field reserved for future use by the Accredited 
Standards Committee X9. 

Usage: Mandatory 

Position: 75-80 

Size: 6 

Type: B Blank 
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2 1 File Control Record (Type 99) 

The File Control Record is mandatory and contains eight fields. It is the final record of an electronic check exchange 
file. The data in the fields are created by the institution sending the file, the immediate origin institution- 



FIELD 


FIELD NAME 


USAGE 


POSITION 


SIZE 


TYPE 


A 
1 


Record type 


M 


01 -02 


2 


N 


2 


Cash letter count 


M 


03-08 


6 


N 


3 


Total records count 


M 


09-16 


6 


N 


4 


Total items count 


M 


17-24 


8 


N 


5 


File total Amount 


M 


25-40 


16 


N 


6 


Immediate origin 
contact name 


C 


41-54 


14 


AIMS 


7 


Immediate origin 
contact phone 
number 


C 


55-64 


10 


N 




Reserved 


M 


65-80 


16 


B 
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21.1 Record type 

A code that identifies the type of record. 



Usage: 

Position: 

Size: 

Type: 

Defined 
Values: 

21.2 



Mandatory 
01 -02 
2 

N Numeric 

4 99* File Control Record 
Cash letter count 



The total number of cash letters within the electronic 
check exchange file. 

Usage: Mandatory 

Position: 03-08 

Size: 6 

Type: N Numeric 

2IJ Total records count 

The total number of records of all types sent in the 
ECE file, including the file control record. 

Usage: Mandatory 

Position: 09-16 

Size: 8 

Type: N Numeric 

21.4 Total Items count 

The total number of items sent within the ECE file, 
all check detail records (type 25) and all return 
records (type 31). 

Usage: Mandatory 

Position: 17-24 

Size: 8 

Type: N Numeric 

21.5 File total amount 

The total US dollar value of the complete ECE file, 
all check detail records (type 25) and all return 
records (type 3 1 ). 

Usage: Mandatory 

Position: 25 - 40 

Size: 16 

Type: N Numeric 



2 1 .6 Immediate origin contact name 

A contact at the institution that creates the ECE file. 
Usage: 



Conditional Shall be present, unless 
omitted under clearing arrangements. 

41-54 

14 

ANS Alphameric/Special 
Immediate origin contact phone number 



Position 
Size: 
Type: 
21.7 

The phone number of the contact at the institution 
that creates the ECE file. 

Usage: Conditional. Shall be present, unless 
omitted under clearing arrangements. 

Position: 55 - 64 

Size: 10 

Type: N Numeric 

21.8 Reserved 

A field reserved for future use by the Accredited 
Standards Committee X9. 



Usage: 
Position: 
Size: 
Type: 



Mandatory 

65-80 

16 



B 



Blank 
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Annex A 
(normative) 

Standard On- Us field format 
A.l ANSX9.I3 definition oftheOn-Us field 

TK A^n"",^^ H e Standard ° n " Us FieM F0rmat is manda,cd «* ,he s,ruc,ure and «*e of the On-Us Field 
"f , ■ U ? d " .""i f t f n < dard ' the 0n - Us Field is loca,ed " betw «n the Amount and Routing fields in 
pos.tions 13 through 32."and "defines the boundaries within which On-Us data may appear, typically the Account 
Number, and optionally, a serial number and/or transaction code." Account 

^?. X c l3 u n ! P ? eS ftW addilional requirements on the structure and contents of the field. It does require that the 

£ n! k W T 8 ^L t0 ' he rieht of ,hc Account Number - 11 a,lows on « additional On-Us Symbol in the 

On-Us F.eld to bracket MICR numerical data. The Dash Symbol may be used as a separator in the On-Us field 
however, the ANS X9. 1 3 standard recommends that issuing institutions consider the use of blank spaces to serve the 
same purpose. The maximum number of characters allowed in the field is 19. 

A.2 Standard On-Us field format 

Prior to the development of ECE collecting banks were only required to capture the dollar amount and routing 

fi^ST! F*7 n S M he t k - J heref ° re - C0,,eCti,,8 b3nks OP™ 1 * « ransit «*«*• " 4i '™8 «he samf 
logic used .n reading their On-Us checks, recognizing fields pertinent to their own internal systems and ignoring 

problem"' envlronn »«« P a y™g banks need their own MICR lines to process, this approach causes 

Because ANS X9.I3 allows paying banks flexibility in the design of the On-Us Field on their physical checks is 
structure can vary from bank to bank. Since this field is not uniformly structured by all banks, paying banks cannot 
easily communicate the., On-Us structure to all collecting banks. Without knowing each paying's On S 
structure the collectrng bank cannot always interpret the On-Us Field accurately in order to place discrete da " 
elements from the On-Us F.eld of the physical document into their corresponding discrete fields within an ECE file. 

\L 0t ^°^uT^r ,k f'Tt" 1 ANS ™ ,3 ' ANS X9 37 re « uires that ,hc c «» ccti "8 bank capture 
the entire On-Us Field from the physical check. The collecting bank must be able to place the On-Us Field from the 

chcTfiltls 11 K 0 "" US Fi6 !, d ,° f ? C ECE fi ' e in,aC, and ' he Same as °» Ph^ical 

stoMrJ' suppressed, dashes are optional and each On-Us Symbol mus t be translated to a forward 



1 1 ANSI X9.I3 ( 1999): Specifications for Placement and Location of MICR Printing 
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Annex B 
(normative) 

Interim On-Us Held fixed format 



B.l Issue 

In a paper environment, a collecting bank is only concerned with the Routing Number and Dollar Amount fields on 
the MICR line of a Transit check. However, in an ECE environment, the collecting bank must also provide the On- 
Us Field which contains paying bank posting information such as the account number and check serial number. In 
the process of developing this standard, the working group discovered variability in the use of the 19-position On-Us 
MICR Field, all of it compliant wilh ANS X9.13. 

B.2 Background 

The structure of the Imposition On-Us Field on the MICR line is left to the discretion of the paying bank. The On- 
Us symbol must always appear to the right of the account number. A second, optional On-Us symbol may be used to 
bracket MICR numerical data. Data placed to the left of this second On-Us symbol may be referred to as Optional 
Field Four Since ECE checks require all relevant On-Us data in order to post, the issue is how the collecting bank 
should capture and forward this information to the paying bank. For a more detailed discussion of On Us Field 
issues, please refer to Annex A. 

B.3 Objective 

The objective of this annex is to define an option, referred to as the Fixed Format Option, which provides a 
migratory path for financial institutions which wish to participate in ECE and have systems which capture in fixed 
- field formatrAt-present,-lhese systems-may-not recognize and accommodate-all the.data_which can_be„conta*ned in 
the On Us field of the check MICR line. 

It should be noted that the working group was aware that financial institutions had ECE development projects 
already in place. It was the working group's intention to provide the widest possible latitude for financial institutions 
to develop and implement ECE. However, it is to be emphasized that the option presented in this annex should be 
viewed as an interim solution, to facilitate development efforts already in progress and to be implemented under 
clearing arrangements. It is the intention of the working group to remove this annex at the five year review. 

B.4 Interim fixed format option 

The Interim On-Us Field Fixed Format option allows users to define the MICR On-Us Field, on both the Foward 
Presentment Check Detail Record (Type 25) and the Return Record (Type 31) as two discrete fixed-length fields. 

This option may only be used when the MICR line has the following characteristics: 

• The On-Us Field contains only one On-Us Symbol 

• The On-Us symbol is printed to the right of the account number 

• The account number contains no more than 14 characters 
The Process Control Field contains no more than 6 characters 1 



The use of 20 byies for the On Us field in no way suggests that 20 chanttlm can physically be accommodated on (he MICR line 
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Annex C 
(normative) 

Interim Payor Bank Routing Number Check Digit Treatment 



C.l Issue 

™ h ,- Ck ^ " R f° ° rd (TypC 25) and the Return Record < T ypc 3 1 > ***** how information located on the check 
MICR line shall be formatted and transmitted. These records require that all information appearing in the MICR 
line shall be placed in record type 25 or record type 3 1 , and transmitted to the final destination of the file 
7^™;? financial institutions today do not currently capture, store, or transmit all information found on the 
check MICR line . One piece of MICR line information not always captured, stored, or transmitted is the Payor 
Bank Routing Number Check Digit. 

C.2 Objective 

The objective of this annex is to define an alternative treatment of the Payor Bank Routing Number Check Digit 
This alternative will provide a migratory path for financial institutions which wish to participate in ECE and have 
systems which do not capture, store, or transmit all information found on the check MICR line. 

It should be noted that the working group was aware that financial institutions had ECE development projects 
already in place. It was the working group's intention to provide the widest possible latitude for financial 
institutions to develop and implement ECE. However, it is to be emphasized that the alternative presented in this 
annex should be viewed as an interim solution, to facilitate development efforts already in progress and to be 
implemented under clearing arrangements. It is the intention of the working group to remove this annex at the next 
live year review. 

C.3 Interim Payor Bank Routing Number Check Digit Treatment 

Within the check detail record (type 25) and the return record (type 31). the payor bank routing number check digit 
is assigned to field 10.5. and field 13.3 respectively; the usage condition assigned to these fields requires that if a 
payor bank routing number check digit is printed on (he check, it shall be transmitted to the final destination 
financial institution The interim treatment for field 10.5 and field 13.3 would allow the ECE institution to 
eliminate the payor bank routing number check digit from the check detail record, even if the check digit appears on 
the check. As noted in section C.2, this alternative treatment may only be used under clearing arrangements 



^!LT ?°? Tlu^ ^ ° fi ? nCial inS,ilU,i ° n ° bU,im lhc mOT ^ numbcr chcck K would be permissible, for 

Example, lo calculate the digit pnor to ihe creation of the ECE file 
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Annex D 
(informative) 

MICR valid indicator 



D. 1 Use of the MICR valid indicator 

The MICR Valid Indicator is a conditional one character field in the Check Detail Record (Type 25); it is present 
only under clearing arrangements. Not all banks exchanging ECE files will use the field. There are, however, three 
reasons for using the field which ECE institutions may wish to consider. One relates to paper handling, two relate to 
accounting. 



D.2 Paper Handling 

The collecting bank may use the MICR Valid Indicator field to notify the paying bank that it has identified a 
problem in reading the MICR line of the check; either a field is missing (e.g. On Us Field) or the collecting bank's 
capture system discerns the presence of a MICR character but cannot interpret it, replacing the unreadable character 
with an " * *\ Use of values other than "Good Read (I)", in the MICR valid Indicator field, usually implies the check 
cannot be posted from the electronic file. Collecting banks may want to include checks on the file that will not be 
eligible for posting; when paper follows the ECE file, the collecting banks may prefer to include all checks on the 
file rather than sort these checks into separate pockets. 



D.3 Accounting 

This indicator will facilitate collecting bank's and paying bank's internal accounting for ECE. 
D.3.1 Settlement 

Exchanging banks may agree to perform two settlements, an initial settlement on the amount of the checks that can 
be posted from the ECE file and a second settlement based on the physical items. 



D.3.2 Net Reciprocal Accounting 

This process allows two banks electronically exchanging checks to net the dollar amount of the postable checks and 
use the net amount for posting purposes. 
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Annex E 
(Informative) 

Commingling of transaction types 



£.1 Commingling of transaction types 

Commingling is the act of mixing two or more different collection types in a single file under this standard 
Collection types defined in the standard are: Forward Presentment, Forward Presentment-Same -day Settlement, 
Preliminary Return Information, Return Request for Truncated Items, and Return Notification. Commingling also 
refers to combining checks intended for multiple banks in the same bundle. 

In general, collection types are not commingled except where permitted by rule, or by agreement between sender 
and receiver. Examples of commingling permissible under the standard arc: 

• Checks intended for multiple paying banks may be commingled in the same bundle, within a designated 
collection type, e.g., Forward Presentment. 

• Qualified Return Checks (QRC) may be commingled within the Forward Presentment Collection Type and 
Forward Presentment - Same -day Settlement Collection Type bundles. 

• Cash letters of different collection types may be commingled within a single flic. 



The Standard does not support: 

• Bundles of Return Notifications and bundles of Preliminary Return Information Items commingled with 
bundles of Return Requests for Truncated Items in the same cash letter. Return Notifications and 
Preliminary Return Information items are informative and have no settlement value. Return Request for 
Truncated Items have settlement value, and therefore must be in a separate cash letter. 
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28 - 29, 32 - 34, 43, 45, 54 - 56, 60 

Bundle business date 31 - 32 

Bundle Control Record 3 - 6, 8, 10 - 12, 

14 -16, 20, 53 -54 

Bundle count 53 - 54, 59 - 60 

Bundle creation date 31 ( 33 

Bundle Header Record 3 - 4, 6 - 8, 10 - 12, 

14-16,20 -21,31 -32. 37, 53 

Bundle ID 3^ 33 

Bundle sequence number 31, 33 

Bundle total amount 53 . 54 



Bank 1.3, 26, 47 -48 

Bank of first deposit .... 1, 27, 31, 37 -40. 45 - 48 
Bank of first deposit 

(BFD) routing number 47 

BFD 1 - 2, 23:37 -40, 46~48 

BFD business (endorsement) date 39. 47 

BFD business (endorsement) 

date confidence indicator 47 

BFD deposit branch 38, 40, 46, 48 

BFD deposit branch confidence indicator 48 

BFD indicator 34. 37 

BFD item sequence number 39, 47 

BFD item sequence number 

confidence indicator 47 

Blank 1 . 5, 22 - 23, 26, 30, 33, 37, 42, 

47 - 48, 50, 52, 54, 56, 58, 60, 62 

Box 2, 55-56 

Box bundle count 55-56 

Box number ID 55-56 

Box sequence number 55 - 56 

Box Summary Record 3, 5. 10, 12, 55 - 56 

Box total amount 55-56 

Bundle 2-4, 6, 8. 10-12, 14-16, 20, 



Cash letter 1 - 3. 5 - 6. 8, 10 - 12, 14 - 16, 

18, 20, 28 - 29, 32 - 33, 45, 55 - 58, 60 

Cash letter business date 27 - 28 

Cash Letter Control Record 3, 5 - 6, 8, 11, 13, 

15, 17-18, 20. 59 '-60 

Cash letter count 59-62 

Cash letter creation date ...27-28 

Cash letter creation time 27, 29 

Cash Letter Header Record 3, 5 - 8, 10 - 11, 

13-16, 18 -21,27 -28, 59 

Cash letter ID 27. 29 

Cash letter total amount 59-60 

Check 1 - 4, 22. 34 - 40, 44 - 45. 

47-48, 50, 58,61 -62 

Check Detail Addendum A Record 3-4, 

10,23,38-39 

Check Detail Addendum B Record 3-4. 

10.41 -42,52 

Check Detail Record 3 - 4, 6 - 13, 20 - 21, 

29, 34 - 39. 41 , 44, 54, 58, 60, 62 

Check Detail Record 

Addendum Count 4 ( 34 ( 37 

Collecting bank 2,3 

Collection type indicator 3 - 5, 27 - 29, 

31 - 34, 43 
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Correcting institution routing number 39 

Country code 24, 26 

Cycle number 31 , 33 



Dash 

Data justification 

Deposit account number at 8FD . 

Deposit account number at BFD 
confidence indicator 



22 

22 

. 23, 46, 48 



Documentation type indicator . 



.46, 48 
36 



ECE 2 - 3, 6, 23, 27, 31.37 - 39. 

42 - 43. 45, 53, 55. 57, 59, 62 

ECE file 3, 23, 55, 62 

ECE institution 2. 27, 31, 37 - 39, 43. 45, 

52.- 53, 55, 57, 59. 

ECE institution forward item 
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J.1.86 Truncation 

The non-return of checks, either to the issuing bank or to the issuing individual, and the discard and 
destruction of the source paper document. 

J.1.87 Translator 

Like Fll-translator in a larger context that includes other applications, not just financial applications. 
J.1. 88 View 

A single instance of a digital image of an item. A single view typically would be of all, or a portion, of one 
face (i.e. front or back) of the item. A single item may be represented by multiple views comprising a view 
set. 

J.1.89 View parameters 

Those data elements of a digital image which are required to interpret and process the image raster data 
correctly. Examples are the image size, spatial resolution, number of gray-scale levels, orientation, etc. 
The image parameters are usually included in the view processing data. 

J.1. 90 View processing data 

That portion of an interchange which contains information that allows the image raster data to be 
interpreted for correct rendering of a view of an imaged object 

J.1.91 Workflow 

in i maging software, a program that q ueues, tracks, and otherwise manages documents and collections 

-<rf-documentSHas4hey-progres^^ 

organization, to their final destination. 

J.I. 92 Zone 

A rectangular area within an image. 
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J.1. 78 Spatial scan density 

The number of pixels used to describe a region of an image of fixed spatial size. 
J. 1.79 Supplier 

The SUPPLIER ([S]) in this specification is the Fit-translator iox interaction between Fll-system-user and 
Fll-translator, and the Transfer-Facility for interactions between Fll-translator and Transfer-Facility. The 
notion of SUPPLIER is imported from CCrTTs X.403 [9]. Abstractly, the term identifies the generic role 
that an application entity plays in the exchange of interchanges. A SUPPLIER provides services 
consumed by a CONSUMER. For example, the Fll-translator is a SUPPLIER which provides services 
consumed by an Fll-system-user. Likewise, the Transfer-Facility is a SUPPLIER which provides services 
consumed by an Fll-translator. 

J.1.80 Text 

Alphanumeric characters and symbols represented by ASCII code. 
J.I. 81 Thresholding 

The process of converting a gray level image to a black/white representation. Typically this involves 
comparing each (gray) image pixel to a block of its neighboring pixels and, based on the relative 
differences in intensity, replacing that pixel's gray level with a "1" or "0°. 

J.1 . 82 TIFF (Tag image file format) 

A de-facto PC standard file format for image data. Its acceptance is world wide. TIFF files contain data 

etem ents -erwoded-using ~a-t ype---len 

resofiftiorToompre^ 

length tells the TIFF decoder where the current tag's data value ends and where the next tag starts. The 
order of the tags is irrelevant. The TIFF standard is administered by Aldus Corporation. 

J. 1.83 Transaction 

A transaction is a physical or electronic representation of an exchange which represents a monetary 
value. 

J.I. 84 Transaction Set 

A Transaction Set is an ASC X12.6 defined EDI term which represents the collection of data representing 
one or more commercial transactions that is exchanged between the parties engaged in electronic data 
interchange. Each instance of a transaction set is composed of a specific group of segments that 
represent a single business document. Each transaction set consists of the transaction set header (ST) 
as the first segment and contains at least one data segment before the transaction set trailer (SE). A 
segment is the intermediate unit of information in a transaction set Segments consist of logically related 
data elements in a defined sequence. 

J.1. 85 Transcoding 

Transcoding is a process of mapping the original compressed image data into new compressed image 
data such that the new compressed image data are different from the original compressed image data, 
regardless of compression aigortthm(s) used. The transformation of image data compressed by one 
compression algorithm into image data compressed by a different algorithm is transcoding. 
Decompression of compressed image data followed by recompression using the same compression 
algorithm, is also a transcoding if the recompressed Image data are not identical to the original 
compressed data. 
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2. Non-Repudiation of Submission: provides the originator of data with irrevocable proof that the 
data was submitted to a server application. 

3. Non-Repudiation of Delivery: Provides the originator of data with irrevocable proof that the data 
was delivered to the intended recipient (application). 

J.1.72 Resolution 

Resolution identifies the relative degree of an image's visual acuity, or it is a measure of capability to 
delineate picture detail. 

In electronic imaging, specific pattern and number of pixels sampled (commonly stated in units of "pixels 
per inch*). 

NOTE - Resolution in general is a word with many connotations. Sampling Resolution, or addressability, as 
defined above, relates only to the number of individual samples taken per unit distance during the scanning 
process. Other aspects of an image system, e.g. the lens, image motion or blur, array cross-talk, can reduce the 
visual sharpness of an image. A bet ter scientific method for defining overall system resolution is the MTF 
(Modulation Transfer Function) or CTF (Contrast Transfer Function). 

J.1.73 Run-length encoding 

The transmission of numbers describing the lengths of white and black regions of an image rather than 
sending separately each black or white pixel. Such encoding is the basis for many of the data 
compression methods used in digital representation of images. 

J.1.74 Scaling 

The process of converting an image from one resolution to another. For example, if an image scanned at 
300 dpi-needs to be primed at-20^ 

"the number of pixels Tfs^to^^^ tfie~ size of the image object is 

increased or decreased accordingly. Numerous algorithms can be used to scale image data up (increase 
the resolution) or down (decrease the resolution). 

NOTE - A scaling operation which increases resolution does not increase the information content or detail 
- e.g. scaling a 200 dpi image to 300 dpi does not increase the image quality. 

J. 1.75 Scan line 

A scan line is the building block of a raster Image. It is a contiguous string of pixels. 

Each scan line contains X pixels. An image is made up of Y scan lines. The pixels in an image form a 
matrix of Y rows and X columns. The pixels in the first scan tine form the first row of the matrix. The first 
column in the matrix includes the first pixel in each scan line. 

J. 1.76 Services 

Application to application interchange including, for example, receipt verification, re-transmission, 
acknowledgment, transmission request, etc. 

J.1.77 Snippet 

An item view representing a portion or subset of an Item face. A snippet is a "partial 11 view of an imaged 
item. The view conveyed in the snippet will generally be a named region of interest of the item face, such 
as, the courtesy amount zone, payee line, signature, etc. It is a portion of the original item's image raster 
data. 
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J.1.65 Page 

A page is the basic building block or "unit of work" used to create a document. A page corresponds to a 
rectangular area that is used for presenting the content of a document on a physical medium. A 
document is a logical collection of pages. 

The contents of a page are defined by the document application. A page may consist of any combination 
of text, images, and graphics. For example, a page may contain one or more images of item views for 
presentation. 

J.1.66 Partial view 

See Snippet 

J.1. 67 Pel (picture element) 

See pixel. 

J. 1.68 Pixel (picture element or pel) 

The smallest addressable point of a digital image. For a black/white image, a pixel is represented as one 
bit (i.e. 0 or 1). For a gray-scale image, the number of bits used to represent a pixel depends on the 
number of gray levels which can be rendered for each pixel (for example, a digital gray-scale image 
whose pixels can represent one of 256 levels of gray would have each pixel represented as an 8-bit byte). 

J. 1.69 Port 

The term PORT is a modeling tool. It is imported from CCITTs X.403J9] i forthe J>urpqse of clarifying what 

' is exchanged between abstract application en^ 

terms, the functionality (in the fonm of operations) that is provided by the supplier to the consumer of the 
service. Although the precise application interface is not specified, the abstract operations that are either 
consumed by the user abstract application or supplied by the 

For instance, the Rl-system-user (the financial institution's image capture application) would be a 
consumer of sen/ices of the Fll-translator that is defined in this specification. 

The term abstract Is used because how the implementation provides these services across its interface is 
outside of the scope of this specification. 

NOTE - One logical consequence of the port notation is that one could easily extend this notation into an 
application program interface by applying a little imagination. 

J.1.70 Protocol 

Rules, definitions, data structures and recommendations that specify how two systems should interact 
and exchange data. 

J.1.71 Repudiation 

Repudiation is the ability of someone to refute the claim of someone else that they were involved in a data 
exchange or handled a data item. Security services to protect against such a situation are called Non- 
Repudiation services. Most often, digital signatures are used to provide this service: 

NOTE - repudiation is Normally spoken of in terms of Non-repudiation Services. 

Hence, Non-Repudiation Services provide irrevocable proof to a third party after an event occurs that the 
event occurred as claimed. Three specific instances of Non-Repudiation Services are as follows: 

1 . Non-Repudiation of Origin: Provides the recipient of data with irrevocable proof of the origin of 
the data, its contents, and its associated security label. 
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J.1. 55 JBIG 

Acronym for Joint BMevel Image Group. JBIG is an international ISO/CCITT standard for compressing 
bitonal image raster data. It defines the compression scheme, parameters, and raster encoding to be 
interpreted for the proper rendition of the image. 

J.1.56JPEG 

Acronym for Joint Photographic Experts Group. JPEG is an international standard for compressing 
continuous tone (gray-scale and color) image data. It defines the compression scheme, parameters and 
raster encoding to be interpreted for the proper rendition of the image. 

J.1.57 Lossless compression 

Compression where the original (source) image data prior to compression can be recovered exactly (bit 
for bit) from the compressed image data. 

J.1.58 Local time 

Local time is the time measured at the location of the entity (such as creator of image or interchange 
originator) that populates a value in an interchange. 

J.1.59 Lossy compression 

Compression where the original (source) image data prior to compression can not be recovered exactly 
(bit for bit) from the compressed image data. 

J.1. 60 Media 

Physical method of intercHahge. e:g. wife; tape, diskTetc. ' ~' ~ 

J.1.61 Message 

A block of information sent from a source to one or more destinations. It is the information which makes 
up an interchange per EDIFACT (ISO/IEC 9735). 

J.1. 62 Object 

A collection of structured fields whose content may contain one or more data elements of a particular data 
type. An object may be assigned a name which may be used to reference the object Examples of objects 
are text, image, graphics, and voice. 

J.1.63 ODA 

Acronym for Office Document Architecture. ODA is an international standard which provides for the 
interchange of documents by means of data communications or by the exchange of storage media. 
Reference: Information Processing - Text and Office Systems - Office Document Architecture (ODA), and 
Interchange Format Standard, ISO 8613-1. 

J.1.64 Orientation 

Indication of how an image was scanned at capture time (i.e. in what direction with respect to normal 
viewing orientation). The orientation data relates the scan lines to the visual top, bottom, left, and right 
edges of the document This information is required in order to have the image correctly oriented for 
normal viewing upon display (the image may have to be rotated, mirrored, etc. prior to display so it is 
presented correctly for viewing). See also image raster data. 
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J. 1.45 Image processing 

Includes all image Input, output, enhancement, and transformation operations performed on images. 
J.1.46 Integrity 

1. Integrity policy - Is a security policy to prevent unauthorized users from modifying, viz., writing, sensitive 
information. 

2. Data Integrity- is a means of protecting the data against unauthorized modification. 

NOTE - Integrity is normally referred to in terms of data integrity or integrity policy. 
J.1.47 Interchange 

The data structure of a financial document, or data, to be transferred between institutions. 
J.1. 48 Interchange protocol 

A set of standardized rules, and structures, used to interchange information. This may be as complicated 
as a set of data communication messages, or as simple as a series of phone calls, and carbon-copy, 
delivery receipts. It may include interchange layout, transmission error detection and correction, 
authentication, and data protection (encryption), eta 

J. 1.49 Interchange structure 

The arrangement or layout of data In an electronic medium for purposes of effecting an exchange of 
commercial transaction information. 

_ „ NOTE.- May_in^u^ 1 

J.1. 50 Interchange format 

Same as FIIS syntax. 
J.1.51 Interoperate 

To exchange data (or information) successfully, to interpret and to act upon that data correctly and 
present it to the user application. 

J.1.B2 Item 

An item is the physical representation of a financial transaction. Examples include checks and related 
paper objects such as deposit slips and cash in/out tickets. The monetary amounts of Items, as expressed 
thereon, will be posted in total, or in detail, as a debit or credit to some account in the bank. Items are 
generally referred to by their type, as for instance, cash items, transit items, on us items, clearing items, 
general ledger items, etc. 

J.1. 53 Rem views 

Hern views refers to a group of views which represent a single physical item. The views associated with 
the imaged item may be a frontal, rear, cropped, clipped, compressed, un-compressed, etc., 
representation of the imaged item. 

J.1. 54 ITU-T 

International Telecommunication Union- Telecommunications Sector, is a United Nations organization 
that develops recommendations in the area of telecommunications. 
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J.1.37 Gray-scale 

A measure of the number of levels of light intensity captured from each pixel within an image. Gray-scale 
levels resolved with today's photo detectors range from 4 to 256 levels. The greater the number of gray 
levels captured and retained, the more data that has to be stored and/or communicated (i.e. a one-bit per 
pixel scanner records only black or white, a two-bit-per-pixe! scanner records 4 levels of gray, and a four- 
bit-per-pixel scanner records 16 levels of gray.) 

J.I. 38 Group4(T,6) 

Two common facsimile (FAX) compression/decompression algorithms defined by the CCITTs Study 
Group 8 technical committee are Group 3 defined in Rec. T.4, and Group 4 defined in CCITT Rec. T.6. 
These algorithms typically reduce the size of a normal office document by a factor of 10:1 (CCITT Rec. 
T.4) and 20:1 (CCITT Rec. T.6). Group 4 algorithms only work on bitonal (black and white) images, not 
color or gray-scale images. 

J.1.39 Huffman coding 

Data compression technique that assigns shorter bit sequences to frequently occurring symbols and 
longer bit sequences to less frequent symbols. 

J.1.40 Image object content architecture (IOCA) 

The term Image Object Content Architecture (IOCA) identifies IBM Corporation's content architecture 
which provides a method for deserving images and image attributes. 

J.1.41 Image (digital image) 

:A^gjtal^prii£^ 

interpret the digital representation, the digital representation is created by sensing light reflected from the 
item. 

J.1.42 Image capture 

The operation of converting a human-readable image on paper to a digital representation stored in 
memory, or some other electronic, or optical, or electromagnetic, surfaced storage media. This is normally 
accomplished using some type of scanning device or camera. 

J.1.43 Image key 

A unique value that unambiguously relates an instance of financial data (used by forward presentment 
applications) with its corresponding image or view(s). For the purposes of supporting pan-institution query 
services, an image key shared among institutions should at least be composed of the capture institution's 
name (\.e., identifier), the capture date, and a unique locally determined naming value that distinguishes 
each view of an imaged item. 

NOTE - The interna) policies employed for naming an imaged item, and associating it with its corresponding 
financial data, are outside of the scope of this standard, but externally, an imaged items should employ the 
naming convention cited in this clause. 

J.1.44 Image raster data 

Description of a rectangular, or square, array formed by a number of horizontal scan lines, comprising a 
number of picture elements. The picture elements form vertical rows. The number of scan tines 
establishes the vertical dimension of the array. The number of vertical rows of pixels (equivalent to the 
number of picture elements per scan line) establishes the horizontal dimension of the array. The relation 
of scan lines to the physical object represented is referred to as the image's 'orientation". 
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J. 1.27 Envelope 

A bounding of a document, pages, or objects which encloses the components in the message data 
stream. 

J. 1.28 Facsimile 

A representation of an original item which may differ in appearance from the original in one or more points 
of comparison (see "copy"). 

J. 1.29 Fll (Financial Image Interchange) 

Seeedi. 

J.1.30 Rl-system-user 

Financial application, such as one that is engaged In the exchange of financial image interchange, that 
uses FIIS, in particular Fll-translator, to communicate with another financial application. 

J.I. 31 FIIS (Financial Image Interchange System) 

Financial Image Interchange System is the means by which Fll-sy stem-users communicate with each 
other. X9.46 specifies the FIIS syntax for exchange of Flls. 

J.1.32 Fll-translator 

Fll-translator is the means by which the Rl-system-user interacts with the FIIS by providing operations 
in vocable by the Fll-system-user. FIMranslator assists the financial applications in originating and 
receiving interchanges through these invocations. Fll-transJators-interact~wrth -each--other— via- a 
communication mechanic: ~~ 

J.1.33 Financial data 

Data used to record financial transactions and upon which settlements are made. 
J.1.34 RIP 

Financial Image Interchange Protocol is the FIIS syntax defined in X9.46. 
J.1. 35 Financial institution 

Any institution that participates in a financial transaction process involving the qualification, disbursement, 
or exception handling of check transactions, or other financial instruments that represent money or 
financial obligations. 

An organization that engages in financial operations (Oxford dictionary). 
J.1. 36 Gray code 

A coding scheme named after the inventor (i.e., Mr. Gray). The conversion from a decimal number to a 
binary number is reordered, such that only one bit changes when the corresponding decimal value is 
incremented, or decremented. 
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J.I. 18 Cropping (Windowing) 

The process of masking (hiding) those parts of an image that are outside of a defined boundary, such as 
a viewing window. It is also referred to as trimming. Pixels outside the defined boundary (i.e., the viewing 
window) are not displayed. The result of the process is the creation a new "reduced" view. The original 
view remains untouched. 

J.1.19 Data stream 

A continuous stream of data that has a defined format. An example of a defmed format is a transaction 
set. 

J.I. 20 Decompression 

The process of restoring compressed data to its original form;, essentially the inverse operation to 
compression. Decompression may be lossy or lossless. 

J. 1.21 Default 

A value as defined in this standard for a given protocol data element (or sub-element) whose semantics 
are understood even if an actual value has been omitted from a segment in an interchnage . 

J.1. 22 Dots per inch (DPI) 

"Dpi" is the unit of measure of spatial resolution of image raster data. A 200 dpi image is one which 
consists of 200 pixels (picture elements) per linear inch horizontally and 200 pixels per linear inch 
vertically. 

. _ J .1. ^ Electronic check exchange (ECE) „ . _ „ - 



The exchange of check information electronically, in lieu of, or in addition to, the exchange of paper 
checks. For forward presentment, usually referred to as electronic check presentment (ECP). In the 
context of HI, it identifies the structure of the financial data identified in this standard, e.g., financial data 
formatted per X9.37 or ECCHO. 

J .1.24 ECE institution 

The financial institution that creates electronic check exchange information for exchange with other 
financial institutions or customers. 

J.I. 25 edi 

To accommodate X12, this standard refrains from using the term "EDI". X12 requires that if the term EDI 
is used, then all data elements, data segments, transaction sets, and functional groups are defined in 
X 12.22 (i.e., the X12 data dictionary.) Since many of the data elements and data segment definitions 
specified in this standard are not duplicated in the X12 data dictionary, the term Fll or "edi" Is used 
throughout this standard. 

J.I* 26 Electronic Data Interchange (EDI) 

Acronym for Electronic Data Interchange. EDI has been standardized in North America by the ANSI 
Accredited Standards Body X12 and at the International level by ISO/IEC TC 154 (EDIFACT). EDI Is a 
method of exchanging information as data, formatted for computer processing, rather than formatted as 
human-readable documents. In , X12 EDI standards are published as part of the series of US standards 
named X12.nn. In ISO/IEC the EDIFACT standard is published as ISO/IEC 9735 multi-part standard. EDI 
syntax being used in this standard is specified in X12.5 and X12.6. 
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J.1 . 8 Character string 

Any group of characters acted upon in a computer system as though it were a single unit 
J.I . 9 Check processing data 

M1CR line information and associated data used in processing paper-based transactions. 
J.1. 10 Clipping 

Defining a region of interest within a larger image (usually by specifying a "clipping' rectangle or clipped 
pixel array within the larger image). Pixels outside the clipping rectangle are retained in the image as 
captured by the image capture device, however, not displayed (or rendered) to the user. 

J.1. 11 Compression 

1) The technique of encoding data to save storage space. Images are compressed before being stored in 
a database or communicated and decompressed prior to being displayed or printed. 

2) Conversion of a digital image to a lower number of bits for storage and/or transmission. 
J.1* 12 Compression algorithms 

Procedures for compressing data sets representing images. There can be many different algorithms for 
encoding image raster data, although currently the CCITT standard facsimile Group 3, 4 compression 
algorithms are the most common for black/white document images. 

J.1. 13 Communication protocol 



A set of conventions or rules involving predetermined sequences of control signals or characters to 
establish, or break, connection, or exchange data between discrete computer systems, within networks, 
(between mainframe and remote terminals), or between a computer and a peripheral. 

J.1. 14 Confidentiality 

The ability to protect against unauthorized access. 

NOTE - Confidentiality is normally referred to in terms of data confidentiality. 
J.1. 15 Consumer 

The CONSUMER QC]) in this specification, using the HIS model outlined in annex D, is either the Fll- 
system-user for interactions between Fll-system-user and Fll-translator, or the Fll-translator for 
Interactions between Fll-translator and transfer facility. The notion of CONSUMER is imported from 
CCfTTs X.403 [9]. Abstractly, the term identifies the generic role that an application entity plays in the 
exchange of interchanges. A CONSUMER consumes services provided by a SUPPLIER. For example, 
the Fll-system-user is a CONSUMER which consumes services supplied by an Fll-translator. Likewise, 
the Fll-translator is a CONSUMER which consumes services supplied by the transfer-facility. 

J.1. 16 Continuous tone 

Image that contains a varying levels of gray densities between black and white. 
J.1. 17 Copy 

An exact representation of an original item (see "facsimile"). 
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Annex J 

(informative) 

Glossary of useful terms 



The following explanations are not necessarily definitions in the strict sense. The terms have, depending 
on the source, varying levels of abstractions and may differ from standard dictionary definitions. When 
encountered in this standard, the definitions contained in this glossary apply. 

J.1. 1 Adaptive btlevel image compression (ABIC) 

ABIC (Adaptive Bilevel Image Compression) is a lossless compression algorithm that is currently used 
with the IBM HPTS (High Performance Transaction System). ABIC is a bilevel algorithm that can be used 
to compress gray-scale images through bit plane processing. Typically, it is used to compress binary 
images and limited gray-scale images up to 16 levels (4 bits) per pixel. 

J.1 . 2 Authentication 

The ability to protect against unauthorized access to a system or service. Authentication is normally 
classified as either strong or simple authentication. There are several methods of authentication that are 
normally discussed: One Way Authentication, Two Way Authentication, and Three Way Authentication. 
All mechanisms involve a method of authenticating that the entity engaging an application is who it claims 
to be. An example of simple authentication is using a password at binding time. For additional information 
refer to ISO/IEC 9594-8. 

. NOTE - A uthenticati on is normally referred to in terms of peer-entityauthentication. 
J.173 Brtonal "™ 

Having picture elements (pixels) expressed in only 1 bit A bitonal view has two intensity values (0 and 1) 
which represent white and black. For example an octet representing brtonal images would represent 8 
pixels because each bit in the octet represents a single pixel. 

J.1.4 Byte (Octet) 

A unit of data expressed in eight bits. 

J.1 . 5 CCITT (Consultative committee for international telephony and telegraphy) 

One of four permanent committees of the International Telecommunications Union (ITU). The CCITT 
creates recommendations. The ITU is a treaty organization whose members are countries. 

In March 1994, the name CCITT was changed to ITU Telecommunications Standardization Sector (ITU- 
T). 

NOTE - AH ITU recommendations issued (and technical committees) subsequent to March 1994 bear the name 
ITU-T, not CCITT. 

J.1 • 6 Character repertoire 

See character set definition. 
J.1. 7 Character set 

Alphabetic, numeric, punctuation, and special symbols that compose an alphabet for a language. This is 
also known as a character repertoire. 
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1.2 Usage of delimiters in interchanges 

EDI interchanges use a type-less grammar lor assembling the interchange. In other words, the 
components are positionalty dependent, and use header identifiers to identify the start erf data structures, 
and separator characters to indicate the end of data structures, or to delineate data elements, and 
subelements. The following example illustrates, by employing BNF notation, the use of header identifiers 
and delimiters in a HI that contains a Financial Data functional group: 

<inter_header> ::= ISA <gs> 



header specific data elements 
delimited by <gs> 



<tr> 

<financiaLdata_fg>::= GS <gs> 
<tr> 

<Jnter_traller> :;= IEA <gs> 

_ tmiler specific data elements . 

delimited by <g$ > - - : - — — ■ — — - 

<tr> 

NOTE - In the above example, the ISA is the (ASC-X12) 3 character code that identifies a start of interchange 
structure, and an IEA identities an end of a trailer structure. More detailed definitions, for all the identifiers, are 
contained in this clause and annex A of this specification. 
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DATA RELATIONSHIP 



INTERCHANGE CONTAINING QUERY 



Query Request FQ- 1 - Start 
p(12Data Integrity and Protection Security -Start] 
pC9 Authentication Security} 
Digital Signature for entire transaction set 
Digital Signature 
[X9 Authentication for Cash Letter 01 -End] 
Query Search or Read Requestor 01 TS-1 -Start 
Digital Signature for entire transaction set 
Digital Signature 
Query search/read 01 - General HI extensions 
Query search/read 81 request criteria 



Query search/read #7r" request criteria 
Query Search or Read Requestor 01 TS-1 -End 
Query Search or Read Requestor 02 TS-1 -Start 



Query Search or Read Requestor 02 TS-1 - End 
[X12 Data Integrity and Protection Security - End) 
— = — Query Request FG-1- End- 
Query Request FG-2 - Start 



Functional GrgupHeader (GS 



FQ Secui 



"■afpfirfi 



Signature Data (SIN) 





ruery Mequest uaxa 



FQ Security Trailer (S1E 




Query Request FG-2 - End 
Query Request FG-*n' - Start 

Query Request FG-'n' - End 




I Interchange Trailer ( IEA ) 



Figure M - Interchange comprising a query request functional group 
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DATA RELATIONSHIP 



Acknowledgment FG-1 - Start 
fX12 Data Integrity and Protection Security - Start) 
[X9 Authentication Security) 
Digital Signature for entire transaction set 
Digital Signature 
[X9 Authentication for Cash Letter 01 -End} 
Acknowledgment 01 TS-1 - Start 
Digital Signature for entire transaction set 
Digital Signature 
Acknowledgment 01 - General Fll extensions 
Acknowledgment 01 request criteria 



Acknowledgment 0'k* request criteria 
Acknowledgment 01 TS-1 -End 
Ackriowtedgment 02 TS-1 - Start 



INTERCHANGE CONTAINING 
APPLICATION ACKNOWLEDGMENTS 



interdgnge H^ct QSA V 



^^o^^eo^^erW^^nc^or^^^b^ 

www 



~ ijfgr^ 



S^ r^re (BIN) 



- Transaction Set Header (ST 



Signature Data (SIG) 



Signature (BIN 



Gercoril FH Extenstons ( GFD ) 





• iransacttonset Iraik 



^Acknowledgments 
[X12 Data Integrity and Protection Security - End) 
Acknowledgment FG-1 - End 
Start 



FG-2-End 
Acknowledgment R5- V - Start 

Acknowledgment FG-*n* 'End 




3fOupTraitef ( 




Figure 1-3 - Interchange comprising an application acknowledgment functional group 
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DATA RELATIONSHIP 



STRUCTURE 



Cash Letters of Views of ttems 1 -Start 
[X12 Data Integrity and Protection Security) 
[Digital Signature] 
Cash Letter 1 - Start 

X9 Extensions to the Xl2to Transaction Set Header 

Bundle 1- Start 

□ > 

One or more views of Item 1- Start 

J > 

View 1- Start 

n > 




General HI Extensions ( GFD 



(GFD ) 



Item Sub^^ 



Item tnfo ff=or Views 



View l-End 
<View3 2+> 

Item I - End 
<Jtems2+> 

Bundle 1 -End [ 
<Bundl6 2+> 



"X^lStteTi^Ena 



Related Cash Letters 1 -End 



Related Cash Letters "n" - Start 



Related Cash Letters V - End 




Figure 1-2 * Interchange comprising an Hem views functional group 
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Annex I 

(informative) 

Diagrammatic representations of an HIS Interchange and delimiter usage 



This annex provides a diagrammatic representation of the interchange by functional group, tt is intended 
to offer a visual reference for gaining insights into the interchange structure. 

1.1 Diagrammatic representation of the Fit. 

DATA RELATIONSHIP INTERCHANGE CONTAINING FINANCIAL DATA 



Cash Letters 01 Posting Data FG - Start 
[X12 Data Integrity and Protection Security) 
peg Authentication Security) 
Digital Signature Posting Data 
Digital Signature 
peg Authentication tor Cash Letter 01 -End) 
Cash Letters 0 1 Posting DataTS 
Cash Letter 01 - General Fit extensions 
Cash Letter 01 Posting Data 
Cash Letters 01 Posting Data TS 
[Cash Letter 91 Security - End} 
— — Cash Letters 01 Postisy Datal?Q -~End 
Cash Letters 02 Posting Data FG- Start 



Cash Letters 02 Posting Data FG - End 
Related Cash Letters Start 



Related Cash Letters V - End 



Interchange Header { ISA ) 



Transaction 



Slgn^reO^JSJ^GJ 



Signature (BIN 



General Rl Extensions ( GFD 



EBE25H5SE2 



Financial Ooto (BIN 




Figure 1-1 - Interchange comprising a financial data functional group 
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User Known Financial Date 



Rem Views Transaction Set 



WCfl Address 
Account Number 

<tS — fBf_ld> 

ECE Business Processing Dan 
ECE Bank Name 
ECECyctoftm 



ltem\ 
Functional Group 



Item Group 
Transaction Sot 
<tnins_sot.hoadaT> 



I torn Subgroup 
<toop_header> 



(tern Data 
<toop_header> 



Nam li 
<ts_cros$_rotore n cos> 



Rem View Data 
Segment 



Item Data Loop Trailer 



ttem Subgroup Loop Trailer 



Transaction Set Trailer 
<trans_seLtrailer> 



Functiona] Group Trailer 
<fQ_balJor> 



Figure H-2 - Cross-reference views by user to view data segments of interchange 

Search and retrieval operations may request views of items by their M1CR identifying information or ECE 
details. The resulting F1I transmission indicates the requesting HI cross-reference at the transaction set 
level. This is illustrated in figure H.3. 



Returned View tnterctrariflfi- 



-Query Request 




Query 
Functional Group 



<ojuery.jBqueslJP> 



Transaction Set Header 
^rans_s<OwadeT> 



General Rl Extensions 
<ts_ref_kl> 



Query Request Data 
«o^iery_requB5t w data> 



Transaction Sel Trafler 
4ransLsetjbB0er> 



Functional Group Trafler 
^Q_traQer> 



Figure H-3 - Query request response containing cross-references 
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Financial Data Transaction Set 



ffimt Views Transaction Sol 




ton Subgroup 



ttaro Dxta Tratter 



SubgroupLoopTnOtr 



ten Group 
TmnMcdonSatTfeOtr 

<tnttfH_8fltJ6f8llOf> 



ttsrn Vtows 
Foncttoral finny TfciDof 



Figure H-1 - Cross-reference views back to financial data transmission interchange 

If the Financial Image Interchange is accepted by a receiving Fll-system-user, and then repackaged into 
another interchange that isjo be sent off to another user, the resulting transmission is considered a new 
— transmission.-Ckirisequer^ 
originator of the new transmission. 

To enable a Fll-system-user to cross-reference a view with financial data that had been received earlier, 
the Fll provides the imaged item's identification information as found in the item's information segment or 
at the transaction set level. This enables the same information to be associated with multiple views of the 
same item without redundantly including this information in each view's detail segments. This is illustrated 
in figure H.2. 
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Annex H 

(informative) 

Cross referencing overview 

This annex provides an overview of the cross referencing mechanism provided by this standard. 

FIIS users have a need to cross-reference other information within the Fll interchange. For example, an 
edi financial data item may refer to a view of an item contained in another transaction set of another 
functional group, or a view of an hem may refer to a financial data item contained in a Financial Data 
transaction set. The mechanisms provided in this standard may be used to satisfy this requirement The 
cross referencing mechanism corresponds to an Fll heading field specifically designed to contain cross 
referencing information. The Fll-system-user arbitrarily chooses an application cross-reference ID. The 
Rl-translator then uses information supplied by the Fll-system-user to pair this cross-reference id with a 
globally unique functional group identifier or transaction set identifier and stores both in the cross- 
reference in the corresponding functional group or transaction set cross-reference field. The cross 
referencing services supported in the FIIP are as follows: 

• functional group to functional group; 

• transaction set to transaction set; 

• item (view) bundles segment to financial data transaction set; 

• item view data segment to item segments; 

• Item cash letter to financial data cash tetter, when a single financial data cash letter is contained 
in a single financial data segment; 

ZJZmZ—tiewdetaib to financial data^ft^ 

The identifier for a detail segment builds on the identifier for its parent transaction set, or loop segment. 
The identifier for a transaction set builds on the identifier for its parent functional group. The functional 
group identifier is composed of the originator's identifier, originator's business date, and a function control 
number all of which are found in the function header (GS segment). The Functional Group Control 
Number is unique within that financial image interchange and across all interchanges originated by a 
sender for a specific functional group date. Its value is determined by the originator of the functional 
group. The resulting identifier must be globally and forever unique to enable the referenced interchange 
component to be contained in some other financial image interchange. Identifiers for segments 
subordinate to a transaction set are created by appending a locally determined numeric to its parents 
identifier. 

An Fll-system-user wishing to correlate an item views transaction set or financial data transaction set with 
an application cross-reference ID found within the EDI interchange uses the application cross-reference 
identifier to perform a look up in the cross-reference information. It finds the corresponding functional 
group, transaction set, or detail segment identifier in the data, then can be used to locate, and extract it. 

The Fll-system-user shall supply the Rl-translator the information required to create the cross-reference 
information when it requests the Fll-translator to create the financial image interchange. Similarly, the Fll- 
system-user can use the cross-reference data when processing the received financial image interchange. 

For informative purposes, only figure H.1 illustrates the mechanism's capabilities. In this example, 
transaction set 1, a financial data transaction set, is referenced from within the FIIP by a view of a 
financial item's data segment This enables the correlation between a particular item in the financial data 
transmission, either contained in this interchange or in another one,. The local reference identifier is 
"12345". 
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Transmission 1: 
FH-translafror*a resulting protocol 



Transmission 2: 
FIMranfllatef^a resirftimi protocol 



SAttsad* 



[Financial Data] 
Functional group 



(RnandaJ Data} 
transaction sot header 



General FH Extensions 



Financial data 



Transaction Set Traitor 



Functional Croup Traitor 
<fQ.traisr> 




tntorehangs 2 
ISAH 



[Item Views] 
Functional group header 



[rtern Group] 
transection set header 



General FU Extensions 

-<t»jeUA>=»i 
<Jg_<Jate>*~ 



<tX»cfos>,fQfDfences> 



Item Subgroup 
<toop.ji>afla»> 



Item Subgroup Information 

<isdJBUa>::»( - - 
• -><*je!Jeb>V 



Item tnfonnetfion 



Hem Data Information 

- • ^tefrueUd>=« { 

<to4je( ja>* • << - 
<1ocBCystue> | 



item View 



Item View 

aocaLvah»> ) 



Item View 
<toop_ eaftdr> 



Item Information 



Item Subgroup 



Set Trader 



Rincttonal Group Trailer 



Figure G-2 - MuttMrensmission RIS transaction set naming and cross reference use of names 
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For informative purposes only, figure G.1 illustrates the mechanism's capabilities. In this example, 
transaction set 1, an Item Views functional group is named by the originating Fll-translator using the 
application <inter_control> identifier that was proposed by the user. The value of <inter_control> as 
proposed by the user is "1 234". 



Fit-translator's resulting protocol 





[Kern Views] 
Functional Group Header 




[Item Group] 
Transaction set header 




<te_retjd> :vs { 




<fg_date> 
<app_senderjd> 
<ftjncttonjoofltf©L_nufftb©t> 
<trans_s^_oontioLnuntf)ef>) 




General FU Extensions 




Item Subgroup Loop 




Transaction Set Trailer 

4ransjBet_tra2er> 




Functional Group Trailer 




— ~ . <jgjbaitef> 



Figure G-1 - FUS functional group naming 

Figure G-2 illustrates the hierarchical internal interchange naming convention used in this Standard and 
illustrates how it should be employed for cross referencing transaction sets across interchanges. 
Naturally, the mechanism may be used for cross reference transaction sets within an interchange. 
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Annex G 

(informative) 

Interchange structure naming overview 



This annex provides an overview of the interchange structure naming mechanism provided by this 
standard. 

FtIS users have a need to correlate members of the interchange and to cross reference information within 
an interchange and across interchanges. For example, an edifinancial data item is carried in a transaction 
set which Is has child relationship with its parent functional group. This naming convention enables 
originating and receiving users to: 

• Evaluate and resolve transfer rejections by receiving Fll-translators and users; 

• Cross reference financial data transaction sets or functional group with view functional groups, 
transaction sets, or detail segments all within the same interchange, or across interchanges as 
described in annex H of this specification; 

• Correlate query responses and Fll acknowledgments with outstanding requests. 

The view and financial data, the correlation aspects of provided by the naming scheme support: 

• infra-interchange data structure correlation; 

• inter-interchange data structure correlation; 

The namingscheme employs the following simple concept: 

The Identifier for a detail structure builds on the identifier for its parent structure. The Identifier for 
the segment immediately subordinate to a transaction set builds on the identifier for its parent This 
standard does not define a new identifier for a functional group. However, it requires that the 
functional group identifier generated by a sender not be duplicated for ail the functional groups 
generated for a specific date. The result of this requirement is that a globally and forever 
unambiguous identifier can be designed to enable cross referencing across Interchanges. This 
globally unambiguous Identifier comprised of the following elements: functional group originated 
date, application sender identifier, functional group control number, and transaction set control 
number. Each of these Identifiers is contained in the imported X12 structures. This standard 
requires that the resulting identifier be globally and forever unique to enable cross referencing 
across interchanges. 



To enable the Fll-translator to appropriately develop a transaction set identifier (<ts_refjd>), the Fll- 
system-user may arbitrarily choose a numerical value and propose it for use to the Fll-translator The Fll- 
translator then uses this information, supplied by the Fll-system-user, to populate the appropriate 
identifiers in the interchange. The value provided by the Fll-system-user can be used by the Fll-translator 
to populate the ISA header's <inter_controt> data element This value can then be used as a root value 
to populate values in <function H controLnumber>. Using this scheme the transaction set identifier 
<ts_ref_id>, which is composed of the <function_contro!_number>, is associated via this naming 
thread with the interchange, as it is known to the Fll-system-user. Locally determined numeric values, i.e., 
<local_value> suffix used in subordinate structure identifier (e.g M <isd_ref Jd>, <item_ref Jd>, 
<ftem_viewjd>), used together with <ts_ief_id> as a root identifier, result with an identifier that has a 
naming thread to the name as known to the Fll-system-user, and is globally and forever unique (see 
figure G-2). 
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The interchange of data may be initiated either by routine financial processing procedures, or in response 
to a query. 

Understanding that there are different types of data required for a normal financial process, the FtlP 
Interchange specified herein has been designed to handle the interchange of several types of information: 

a. financial data as defined in X9.37 and other financial groups; 

b. item view data (which contains digitized imaging data, the details required to interpret the image 
encoding information, and financial control data elements); 

a an acknowledgment structure to indicate acceptance of responsibility for an HI and its 
components, or to advise of partial results for a query request; 

d, a query request for images of one or more financial documents (e.g. that match some selection 
criteria); 

e. a means for canceling an outstanding query request 
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this specification. The services provided by the Fll-translator to the Fll-system-user are illustrated in figure 
F.2. As illustrated, the FIIP interchange may contain multiple views of an image-item, or 
acknowledgments, financial data, or queiy request(s) for retrieval of one or more images of items that are 
believed to be held at an institution. 

Financial Image 

Interchange 

(Financial Baa. 
Ackttowtodgmonn\ 
tmapo Views, 
Query Requests) 

Figure F.2 • Fll-translator reception services 



Receiving 

Fll, 
translator 



tem Views 

Financial Data 



Query Request 



Image and 

Data 
Processing 

Application 



FJ2 Fll system model overview 

This document defines an open standard for exchange of financial data, or imaged financial objects, or 
both, across a heterogeneous computing environment. It defines a simple structure, conforming to the 
X12 EDI architecture, to specify an EDI interchange which is tailored to support the exchange of digitized 
images of financial items. 

A model of the Financial Image Interchange System (FIIS) is used to illustrate the level of interchange this 
standard describes. This model is used only as an aid in explaining the use of this Standard and in 
providing a point of reference. It is not intended to be an actual Implementation. As illustrated in figure 
F.3, financial image interchange occurs within this FIIS. This concept is explained further in annex E. 



Ftnondal AiugjB 
Proc es sing App R CBtionB 



Originating 
Applications 



-Rnanctal Data~ 



jtefft Views 



AJuiuwkxiQetneflts' i 



Query Request 



■ i 



Finsttdaf kn&ffo 
Proc es sing AppQcetfosts 



Receiving 
Appflcattoas 



, Financial Data 



ttem Views 



Query Request 



Fll 
Translator 



■i 

:i FIIS 



Fll 
Translator 



Financial Image 
interchange (e<S) Protocol 



| Transfer 
mecnatvsm 



AppScstfon ' 



Figure F.3 - The financial image interchange system model 

The Financial Image Interchange (Fll) fully utilizes X12S EDI standard as a foundation. As with X12, the 
protocol that is exchanged between two Fll-transtators is comprised of an interchange header and trailer 
segment that surrounds one or more defined functional groups. The structures used in this protocol are 
defined in clause 6. 

NOTE - XI 2s data segment definitions and data element dictionary are greatly extended by this standard. 
Furthermore, this standard defines a confirmed ecR service that also supports a query service. 
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Annex F 

(informative) 

System overview and model 



This annex forms a non-Integral part of the standard to elaborate further upon the model used in HI. 

This annex specifies the system overview and modeling concepts used in this standard. The model uses 
a originator / recipient concept where both the orignator and recipient are applications engaged In Fll. The 
events of Fll are activated by either human activies, such as customer relations, or check processing. The 
overview and model, when read in conjunction with the Fll Environment, annex E of this Standard provide 
the reader with an abstract of the interaction standardized for Fll. 

F.1 Functional and system overview 

The Financial Image Interchange Protocol (HIP), defined in this specification, specifies an open system 
format protocol for the exchange of images of financial information across heterogeneous computing 
systems operating in financial institutions. The HIP is provided by the HIS which is modeled as an end- 
to-end, peer-to-peer application formatting protocol. The Fll-translator assists financial computer 
applications in forming and receiving financial data or requests for financial image sets or the image sets 
themselves packaged In accordance with the protocol specified in this specification. 

Although this Standard does not rquire implementing a full HIS environment, it is provided for 
completeness. 



F.1 .1 Origination services 

The originator of an HIP conformant interchange shall originate interchanges in accordance with this 
Standard. The interaction between the image capture and pre-processing application (the Fll-system- 
user) and the Fll-translator is not specified in this Standard, although the external design of what is to be 
exchanged is found in the abstract service definition, annex E of this specification. The services provided 
by the Fll-translator to the FH-system-user are illustrated in figure F.1. As illustrated in this Hgure, the 
image/data capture system may present multiple views of a single image-object-item. The Fll-translator 
can originate financial information objects, such as forward presentment, return notifications, and receiver 
acknowledgments, or images of truncated financial documents such as checks, or requests for imaged 
objects. 



Image and 

Data 
Processing 
Application 



ttamVbwa 



Query Request 



Autttfwifnfion 



Originating 

HI 
translator 



Financial Image 

Interchange 

(FbwtdaJ Oau. 



Query Requests) 



Figure F.1 - Fll-translator origination services 



F.1 -2 Reception services 



The receiver of a FIIP conformant interchange shall accept financial image interchanges in accordance 
with this specification. The interaction between the receiving Fll-translator and the Image rendering or 
interchange processing application (the FH-system-user) is not specified in this standard, although the 
external design of what is to be exchanged is found in the abstract service definition found in annex E of 
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EL3-2 Transfer mechanism 

The FIIS does not specify which transfer or storage media mechanism is to be used by financial 
institutions to move a financial image interchange between financial institutions. It simply r ** uir ^™it 
some mechanism exist between trading partners. Examples of said mechanisms include X.400, FTAM, 
corporate proprietary communications protocols, formatted tape or optical disks, or any other media 
deemed appropriate between communicating peers. 

Also, the communications of an interchange is an end-to-end servioe which may involve the use of 
intermediate relay points. Intermediate Fll-translators forward received transaction sets destined to other 
users by embedding them in a newly constructed interchange. 

The security aspects of the FIIS and the transfer mechanism are a matter of the user financial institution's 
security policy. Together, the transfer mechanism and the Fll are envisaged to meet adequately and 
appropriately, the security expectations of that policy. 
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NOTE - The recipient identifier may be specified as a DUNS number or an ABA assigned Routing and Transit 
Number. 

E.2.4.2 F1IS receive interchange abstract operation 

The Rhsystem-user application assists the Financial Institution's image and data processing application 
in receiving an interchange through the invocation of the Receiveinterchange abstract operation. The 
interchange may contain Fit functional group(s) as defined in 6.2.1 . 

The syntax of Receiveinterchange abstract operation is as follows: 

receive Jnterchange ::= ABSTRACT-OPERATION 
ARGUMENT SET { 

finandaMmage-interchange <fii-stracture> } 
RESULT Q-this operation has no results 

ERRORS { not-available (1 ), 

unwtlllng-to~perform (2)} 

E.3 Secondary object types 

The FIIS can be modeled as comprising lesser objects which interact with one another by means of 
(additional) ports. 

fits-refinement REFINE fiis AS { 
Fll-translator RECURRING 

origination [S] VISIBLE 

reception [SJ VISIBLE 

communications-mechanism 

_ submission __. _[S] INVISIBLE ' ^ 

delivery [S] INVISIBLE } 

These lesser objects are referred to as secondary objects of the Financial Image Interchange System. 
They include a single central object (the communications or storage media) and a single peripheral 
object: the Fll-translator. The structure of the FIIS is depicted in figure E-1 above. 

NOTE - The communications or format medium is considered to be invtslble because it is not defined in this 
Standard. 

E-3.1 Fll-translator 

The Fll-translator assists the financial institution's imaging application in originating, and receiving, 
interchanges through the invocation of the Originatelnterchange and Receiveinterchange abstract 
operations, respectively. The interchange may contain Financial Data functional group(s), Item Views 
functional group(s), Query Requests functional group(s), Functional Acknowledgment functional group(s), 
or Fll Application Acknowledgment functional group(s) as defined in 6.2.1. 

Fll-translator OBJECT 



PORTS { 

origination [S] 

reception [S] 

submission [C] 

delivery [C] ) 



The RIS comprises any number of Fll-translators. 
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Origination port 

The Origination port is the means by which a single user conveys information, used by the Fll-translator 
to construct interchanges of Fll functional groups (financial data, imaged items, query requests, or Fll 
acknowledgments) containing information objects of the type defined in 6.2, to the FIIS for transmission to 
another Fll-system-user. Through such a port, the user originates a Financial Image Interchange. The 
abstract operations available at the origination port are defined as: 

origination APPLICATION-SERVICE-ELEMENT 

CONSUMER INVOKES { Originatelnterchange } 
SUPPLIER INVOKES { OriginateControl } 

originate-interchange ::= 1 - numeric 
originate-control ::= 2 - numeric 

The FIIS supplies one Origination Port to each user. Originate Control abstract operation is for further 
study. 

E2.ZJ2 Reception port 

The Reception Port is the means by which FIIS conveys the interchange, which is composed of Fll 
functional groups (financial data, imaged items, query requests, or Fll acknowledgments) containing 
information objects of the type defined in 6.2, to a single user. Through such a port, the user receives the 
contents of the interchange. The abstract operations available at the reception port are defined as: 

reception APPLICATION-SERVICE-ELEMENT 
CONSUMER INVOKES { RecetveControl } 
- SUPPLIER INVOKES ( Recetvelnterchan ge > . J.'.'.I~ . * ' " " ~ 

recelve-interchange ::= 3 - numeric 
receive-control ::= 4 - numeric 

The FIIS supplies one Reception Port to each user. Receive Control abstract operation is for further 
study. 

E.2.4 HIS abstract operations 

The FIIS provides two abstract operations through its port: the Originate Interchange and Receive 
Interchange. 

E£.4.1 FIIS originate interchange abstract operation 

The Fll-system-user application assists the Financial Institution's image and data processing application 
tn originating interchanges by providing the Originate Interchange abstract operation. The interchange 
may contain Fll functional group(s) as defined in 6.2.1. 

The syntax of Originate Interchange abstract operation is as follows: 

Originatelnterchange ::= ABSTRACT-OPERATION 
ARGUMENT SEQUENCE { 
financial-image-interchange <fii-structure>, 
interchange-recipient Recipient } 

RESULTS Q-this operation has no results 

ERRORS { not-available (1), 

unwilling-to-perform (2)} 

Recipient ::= ASCII (SIZE (35)) 



199 



COPYRIGHT Amor icon national Standards Institute 
Licensed by Information Handling Services 



XP008074623 



X9.46-1997 



E.2 Composition of financial image interchange system (HIS) 

When the FIIS is refined, it is seen to comprise a single central object, the communications mechanism, 
and numerous Fll-translators. There is one Fit-translator for each Fll-system-user, and it is the means by 
which the Fll-system-user interacts with the FIIS. The communications mechanism may include a file 
storage device(e.g., file hand-off), or more elaborate means of electronic communications (e.g., electronic 
mail, or X.25 packet networks). 

When the Fit-translator is further refined, as specified in clause of this specification, it is viewed to provide 
several abstract operations that are invocable by the Fll-system-user, i.e., Financial User Institution 
Imaging Application. This Specification defines two (2) abstract operations: Originatelnterchange and 
Receivelnterchange. These abstract operations form the basis of interaction between the Fll-system- 
user and the Fll-transfator. 

NOTE 1 * The interface between the FII*system-user and the Fll-translator is outside the scope of this 
specification. 

NOTE 2 - The Specification of the Communication-mechanism of the FIIS is outside the scope of this 
specification. 

EL2.1 Financial institution user application 

A Financial Institution User Application is typically a financial institution's imaging application that engages 
in the exchange of Financial Image Interchanges. Such an application is referred to by the term •user*, or 
"Fll-system-user* in this specification. A user originates, receives, or both originates and receives 
Information objects of the types defined in clause 6 through ports. An Fll-system-user object is defined as 
follows: 



Financial image interchange system 

A Financial Image Interchange System (FIIS) is the object by which all users communicate a financial 
image Interchange with one another in an FHE. How HIP objects are communicated is outside the scope 
of this specification. As the primary communication object for the FHE. FIIS supplies the service of 
interchange origination or reception through ports. The FIIS object is defined as follows: 



The FIIE comprises exactly one FIIS. 
Primary port types 

The primary objects of the FIIS are joined, and interact with one another, by means of ports. These ports, 
which the FIIS supplies are referred to as the primary ports of The Financial Image Interchange System. 
They are of the types defined below. 

NOTE - How an RMranslator concretely realizes the primary ports it supplies is beyond the scope of this 
specification. 



fit-system-user OBJECT 
PORTS { 
origination 
reception 



[CI 
[C]) 



tils OBJECT 
PORTS { 
origination 
reception 



IS], 
[$]) 



198 



COPYRIGHT American National Standard a Institute 
Llconeod by Information Handling Services 



XP008074623 



X9.46-1997 



Annex E 

(informative) 

Financial image interchange environment 

This annex describes the Financial Image Interchange environment. It provides useful modeling 3 
information on the services that should be provided by the Fll-translator to its client edi and image 
handling applications. It also sets forth a basis for developing an open application program interface 
(API). This annex is designed to complement and further elaborate upon annex Fs Fll System Overview 
and Model. 



E.1 The financial image interchange environment 

The Financial Image Interchange Protocol (FIIP) Is used to convey financial image interchanges among 
financial institutions that form the Financial Image Interchange Environment (FIIE). 




Figure E-1 - Fll modeling environment 

The environment in which FIIE takes place can be modeled as an abstract object which hereafter is 
referred to as the Financial Image Interchange Environment (fiie). When refined (i.e., functional 
decomposition has been performed), the FIIE can be seen to comprise lessor objects which interact by 
means of ports. 

file-refinement REFINE fiie AS 
fus 

origination [S] PAIRED WITH fif-system-user 

reception [S] PAIRED WITH fiKsystem-user 

fil-system-user RECURRING 

The lessor objects are referred to as the primary objects of the Financial Image Interchange System 
(HIS). They include a single, central object, i.e., the FIIS, and numerous peripheral objects called the 
Financial Institution Imaging Application (Fll-system-user). The structure of the FIIE is depicted in figure 
E-1. 



Ameta-tanguage is used In this annex to desafoe the Bl environment (see [7] ft]). 
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M 


M 


02/02 


AK101 






<furtction_corttrol_niimber> 


M 


M 


01/09 


AK102 






<trans_sel_ responseJoop> 


O* 


C 










<fgL.response trailer* 


M 


M 




AK9 
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Table D.1 (continued) 



Element names for QTS: 
Query request transaction Get 


Protocol 
Support 
(U/O/C) 


Business 
Support 
(M/Bn) 


Size 


Reference 
inFllStd 


Implemented 
(Y/N) 


Remarts 


<auArv ran nest ts> 














<tnins 8flt_h6adGf> [ST] 


M 


M 


V 










o 


B9 


y 








<sianatum data> ffilGl 




648 


v 








^Mtiritu mitt nantA^ 


M 


M 


04/16 










M 


M 
M 


U*t/ ID 








^ntrthont olnrwithm 1/4**. 


M 




01/11 
W If 13 








o(8y_ana^or — oiocK_s(ze> 


u 


B1 1 
til 1 


Ul/Ul 










r\ 
\J 


Dl 1 


Mil IO 










r\ 
\J 












<Dfn^se(jrneni> ibin] 




BO 


V 








<^Bf>Gral_FI l__©xtGnsions> fGFO] 


ii 


M 










<query_fcuesi_ioup> 


U 














oo 


B? 


w 

V 








inn/ root io<rf rtata^. FABffl 


IVi 


M 












M 


M 


01/02 










M 

IVI 


M 


18/50 










v 1 C. 












•tfOfrfAVAl hnAftA lwv> 


C14 


B31 


34/V 










C8 


pqp 


—01/02" 


„ . ._ „ 






- - - — 














<output_ i typo_reQu©stod> 




B28 


01/01 








<secured results re<ju8st_fcfiC3tor> 


o 


B9 


02/02 






















jmaIa viva ram inrtnrl» 


VrO 


Da£0 


U l/UO 










OB 


B9ft 










<DansporLjTieoia_rBQU65iBu> 




B28 










^>rocessinQLpnority> 


to 


BOO 


Ul/Ul 








^1 0 lain_CUSlOuy_uX3KJUUuf l> 




R9fl 
C3_0 


Wl/Ul 








<obso!8tes_Query_r©Qit8St_Jtt> 


U 


BOO. 


O/4/QO 








^nax_Japse„tin>e> 


o 


CtOjt 

B34 


01/06 








<max_fnatching_views reQd> 


o 


BO 


ATMS 








<view Ti sitte„reQuest8d> 


Co 


Boa 


UlrtJi 








<viow_ i snj pp e\_retji uro 


r\ 
\J 


pf»o 


mm 

Ul/Ol 


















































<acceptabte_oompression_ids> 


O 


83 


01/V 








^>avor_bank_rn> 


o 


B35 


09/09 








<eccL^usff)essLdafGL/snoe> 


C13 


B35 










<ecaj>ustoess__date_start> 


O 


B17 


oa/08 








<ece_business_daie_enct> 


O 


B17 


08/08 








< ecG_$eQuence_numt>er__ranoG> 


C13 


B35 










<ece_seo_number_start> 


O 


B17 


01/15 








<ece_.seci_nurnber_.6ftd> 


O 


B17 


01/15 









193 



COPYRIGHT Umar icon national Standards Institute 
Licensed by Information Handling Services 



XP008074623 

X9.46-1997 





Protocol 








Implwitgnteii 

IlllUf^f lid IWw 


Rcaisrlcs 


Query requests functional group 


Support 
(M/O/C) 


Support 
(U/Bn) 




inRIStd 


(Y/N) 




<quefy_requestsjg> 








6.4.4 






<fq_headef> fGSl 


M 


M 


V 


6.3.1.1 






<fQL_eecurity> [SIS} 


O 


B12 


V 


6.3.1.7 






<slgnature_ts> 


O 


B9 


V 


6.3.1.13.1 






<auofy_request_ts> 


M 


M 


V 


6.4.4.1 






<fflusecurtty_traD8r> (S1E1 


C1 


B48 


V 


6.3.1.8 






<fo_trailer> [GEl 


M 


M 


V 


6.3.12 
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Table D.1 (continued) 



Element names for 


Protocol 


Business 


Size 


Reference 


Implemented 


Remarks 


Application Acknowledgment 


Support 


Support 




InFUStd 


OWN) 




functional group 


(M/O/C) 


<M/Bn> 










<appDcation_ackJg> 








6.4.3 






<fq_header> \GS] 


M 


M 


V 


6.3.1.1 






<fa_secumy_header> fS1S1 


O 


B48 


V 


6.3.1.7 






<skj nature _ts> 


o 


B9 


V 


6.3.1.13.1 






<applicatioo_ack_ts> 


M 


M 


V 


6.4.3.1 






<fq_securitY_tmiler> fSIEl 


CI 


B48 


V 


65.1.8 






<fgjrai)er> [GE1 


M 


M 


V 


6.3.1.2 








Element name for ATS: 


Protocol 


Business 


Size 


Reference 


Implemented 


Remarks 


Acknowledgment transaction set 


Support 


Support 




tnHIStd 


(YAH) 






(M/O/C) 


<M/Bn> 










<app!ication_adOs> 


— 


— 


V 


6.45.1 






<trans_set_header> fSTl 


M 


M 


V 


6.3.15 






<ts_security_header> [S2S] 


O 


B48 


V 


65.1.9 






<stgnature_data> fSIl 


O 


B9 


V 


65.1.13.1 






<securfty_ortq_nama> 


M 


M 


04/16 


6.3.1.7.2 






<security_recip__name> 


M 


M 


04/16 


6.3.1.7.3 






outhGnt^akjOftthm zMi> ~~ 


— M— - 


~ M 


-01/15— 


-6.3:1.132:1" 






<fcey_artd_or_b!ock_size> 


5 


bTi 


" 01/01 " 


~&3.i.i322~ 






^©ngth„of^data> 


o 


B11 


01/18 


6.3.1.132.3 






<signatufB> 














<bin_segment> [BIN] 


C8 


B9 


V 


6.3.1.11 






<tj8rteraLRLextensions> [GFD] 


M 


M 


V 


652 






<appDcation_ack_data> [ATS] 


M 


M 




6.4.3.11 






<ack_created_date_time> 


M 


M 


15/15 


6.45.1.1 






<ack_reason_oode> 


M 


M 


01/01 


6.45.12 






<ack_ajagnastic_code> 


M 


M 


01/03 


6.45.1.3 






<subject_ts_reLW> 


C7 


B30 


16/42 


6.45.1.5 






<subjectjsd_re!_ld> 


C7 


B30 


18/50 


6.45.1.6 






<subject_rtern_ref_id> 


C7 


B30 


20/58 


6.45.1.7 






<subject_rtem_viewjd> 


C7 


B30 


22/66 


6.4.3.1.8 






<subject_qrd_jd> 


C7 


B30 


18/50 


6.45.1.9 






<numberjtems matching crtteria> 


C22 


B2 


01/06 


6.4.3.1.10 






<supplemefttaJ_ni{o> 


O 


61 


01/80 


6.45.1.11 






<imaoeJceys_matchinqLCriterta> 


C22 


B2 


34/V 


6.45.1.12 






<restaro>olni_lndicaiion> 


C17 


B2 


01/V 


6.45.1.13 






<ts_seaiTftY_traner> [S2E1 


C1 


B48 


V 


6.45.1.10 






<trans_set_trailer> [SE1 


M 


M 


V 


6.4.3.1.4 
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Table D.1 (continued) 



Element name for: 
Item vtews detail segments 


Protocols 
upport 
(M/O/C) 


Business 
Support 


Size 


Reference 
tnFUStd 


Implemented 
(Y/H) 


Remarks 


<item_views> 


— 


— 


— 


- 






<loop_rteader> [LS (3)] 


M 


M 


- 


6.3.1.5 






<toop_id> 


M 


M 


01/04 


6.3.1.5.1 






<item_view_data> OVS] 


M 


M 


• 


6.42.8 






<ttem_view.Jd> 


0 


B1 


22/66 


6.42.8.1 






<vtew_creatton_date> 


M 


M 


08/08 


6.42.82 






<vtew_ccmpresston_alqo_kt> 


M 


M 


01/03 


6.42.8.3 






<vt8w_rastertata„sizein_bytes> 


M 


M 


01/10 


6.42.8.4 






<v!ew_slde_indicator> 


0 


B2 


01/01 


6.42.8.5 






<pixete_per_Hno> 


M 


M 


01/08 


6.42.8.6 






<number_of_Bnes> 


M 


M 


01/08 


6.42.8.7 






<roso!ution_unit> 


O 


B2 


01/01 


6.42.8.8 






<resolutton_aiong_line> 


M 


M 


01/08 


6.42.8.9 






<rcsotution_acro33„Hne3> 


M 


M 


01/08 


6.42.8.10 






<bits_per_olxet> 


M 


M 


01/01 


6.42.8.11 






<irrterpret_bttmap> 


M 


M 


01/01 


6.42.8.12 






<Oftentartion> 


O 


B2 


01/01 


6.424.13 






<snfpp0t_tnfo> 


O 


B25 


- 


6.42.8.14 






<snlpp©t n narrte> 


C18 


B25 


01/02 


6.42.8.14.1 






^nfppot_orfflin> ...... ... .... . 


C19 


B2S 


. .01/D1-.. 


6.42.8.142 






<srdpp6t_offset> 


C20 


B2S 


"07/27" 


6.42.8:14:3 






<srtippet_units_ot_measure> 


O 


B2 


01/01 


6.42^.14.4 






<ciippiftQ—fafofm3tion> 


O 


B26 


01/45 


6.42.8.15 






«cflpptnQ_orksfn> 


O 


B26 


01/01 


6.42A15.1 






<cUoplna_ofiset> 


0 


B26 


04/43 


6.42.8.152 






<embed<fed_hoader_lnfo> 


O 


B1 


, „„ 


6.42.8.16 






<embeA*ed_header_frxflcator> 


M 


M 


01/03 


6.42.8.16.1 






<vtew,raster_data_offset> 


M 


M 


01/08 


6.42.8.162 






<CTGation_oompiiter> 


O 


B1 


01/32 


6.42.8.17 






<viGw_dcscrtptk)n> 


O 


B1 


01/32 


6.42.6.18 






<scanner_rnfijr_najns> 


o 


B1 


01/30 


6.42.8.19 






<scanner_model_name> 


0 


B1 


01/15 


6.42.620 






vtew_capture_software> 


0 


B1 


01/30 


6.42.821 






<vfew_binary_data> 


M 


M 




6.3.1.11 






<trinary_seament> [BIN] 


M 


M 


otw 


6.42.6 






<toop^traJler> O-E (3)1 


M 


M 




6.3.1.6 






<k»pjd> 


M 


M 


01/04 


62.1.6.1 
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Table D.1 (continued) 



Element name for 


Protocol 


Business 


Size 


Reference 


Implemented 


Remarks 


Item subgroup and item data k>op3 


Support 


Support 




InRIStd 


(Y/N) 






(M/O/C) 


(M/Bn) 










«dtem_subgroup> 















<!oop_header> [LS(1>] 


M 


M 


V 


6.3.1.5 






<loop„ict> 


M 


M 


01/04 


6.3.5.1 






<ftem_subqroup_information> [ISO] 


M 


M 


V 


6.4.2.3 






«tem_data„loop„tentjth> 


M 


M 


02/10 


6.45.3.1 






<isd_ref_id> 


M 


M 


ie/so 


6.45.35 






4sd_item__oount> 


M 


M 


oi«a 


6.45.3.3 






<isd_subqroup_recipient> 


M 


M 


04/18 


6.45.3.4 






<isd_cross_references> 


M 


M 


16/257 


6.45.3.5 






«dsd_subflroup_amount> 


O 


B2 


01/16 


6.45.3.6 






<ftem_ctataLtoop> 


M 


M 


V 


645.4 






<Jooo_header> [LS (2)1 


M 


M 


V 


63.1.5 






<JoopJd> 


M 


M 


01/04 


6.3.1.5.1 






<slc?nature_data> fSIG] 


O 


B9 


V 


6.3.1.13.1 






<siqnaturg> 














<fcin_segment> (BIN1 


C8 


B9 


V 


6.3.1.11 






4temjnformation> [IIH] 


M 


M 


V 


6.4.2.5. 






<rtem_views_lcnalh> 


M 


M 


01/10 


6,45.5.3 






^tenv_fBlJd> 


O 


B1 


20758 


6.45.5.1 






<oompressfOf|_jn(ficator^> 


M 


M 


01/V 


6.45.55 






- — =<vtewzCOunfc> — — - --■ - 




- M - 


01/08 


6:45:5:4 






<£h_cross_reference> 


O 


B23 


167257 


6.45.53 






<tem_an>ount> 


O 


B2 


02/12 


6.45.5.7 






<payor_banlt_ioutina_number> 


O 


B24 


09/09 


6.45.5.6 






<imaoe_kev> 


0 


B2 


34/34 


6.45.5.9 






<user_data _presentJndicator> 


O 


B1 


01/01 


6.453.11 






<user_data> 


o 


B1 


00/V 


6.45.6 






<bin_Sdgment> [BIN] 


M 


M 


V 


635.7 






<item_views> 


M 


M 


V 


6.45.7 






<toop_trailer> [LE (2)1 


M 


M 


V 


63.1.6 






<loopJd> mamm 


M 


M 


01/04 


63.1.6.1 






<ioot>_trailer> fLE fill 


M 


M 


V 


63.1.6 






<loopJd> 


M 


M 


01/04 


6.3.1.6.1 
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Table D.1 (continued) 



Element name for 


Protocol 


Business 


Size 


Reference 


Implemented 


Remarks 


Item views functional group 


Support 
(M/Q/C) 


Support 




InFUStd 


(Y/N) 




<ftem„view3_fg> 






V 


6.42 






<fQ_headar> fGS] 


M 


M 


V 


63.1.1 






<fg_securfty_header> [S1S1 


0 


B9 


V 


6.3.1.7 






<siqnature_ts> 


O 


B9 


V 


6.3.1.13.1 






<rtem_aroup_ts> 


M 


M 


V 


6.4.2.1 






<fo__securttyJraIl8r> [SI El 


C1 


B9 


V 


6.3.1.8 






<fQ_trailer> fGE] 


M 


M 


V 


6.3.12 








Element name for ITS: 


Protocol 


Business 


Size 


Reference 


Implemented 


Remarks 


View set message set 


Support 
(M/O/C) 


Support 
<M/Bn> 




InRIStd 


(Y/N) 




<*tem_group_te> 








6.42.1 






<drans_set_rtaader> [ST1 


M 


M 


V 


63.1.3 






<qeneral_Fll_extensions> [GFD] 


M 


M 


V 


6.32 






<rtem_subaroup> 


M 


M 


V 


6.422 






<trans_set_trai!er> [SE] 


M 


M 


V 


63.1.4 







Compression Algorithms Support 


Protocol 
Support 
(M/Q/C) 


Business 
Support 
<H/Bn) 


Size 


Reference 
mFUStd 


bnptefttented 
(Y/N) 


Remarks 


-<view-cornpression-alqo-U> 


— 


- M-^~ 


01/03 


6.42.63- 






1 (uncompressed) 


O 




01/01 








2 (T6 facsimile compression) 


o 




01/D1 








3 (JPEG Baseline) 


0 




01/01 








4 (JBIG) 


o 




01/01 








5 (ABIC) 


o 




01/D1 








0,6 - 499 (Reserved lor X9) 


o 




01/03 








500-999 (reserved for private usage) 


o 




V 
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Table D.1 (continued) 



Element names GFD: 


Protocol 


Business 


Size 


Reference 


Implemented 


Remarks 


General Rl Extensions segment 


Support 
(M/O/C) 


Support 




InFtlStd 


(YM) 




<general_FILexiensions> 








632 








M 


M 


02ns 


6.3*2.1 






<ts ref id> 


M 




16/42 


6.3.2.2 






>una of ts data> 






ni /rva 










Q 


R19 


01A)4 


6.3.2.4 






^ack eonditions> 


\j 


R19 


wlfWI 


6.3.2.4.1 






^funA of roniiPCt** 




a -to 
DlJe 


m /no 








ock £ecuritv> 

>OM\ B .O0WU 1 II J ' 




R19 
Die 


01/02 


6.3.2.4.3 






^■^w* *u — i ***** ' li^ ll/*' 


Q 


B1S 


04/18 


6.3.2.5 






<ffiJd_qualHier> 


M 


M 


02/02 


6.3.2.5.1 






<fiLack_fBctpiBnt_id> 


M 


M 


01/15 


6.3.2.5.2 






<ts_cross_references> 


O 


B13 


16/257 


6.32.6 






<type_oLfinanciaI_data> 


O 


62 


01/02 


6.3.2.7 






<count_of_financial_data_items> 


C9 


B18 


01/08 


6.3.2. 8 






<oount„ofJmage<JJtems> 


C10 


B19 


01/08 


6.3.2. 9 






<jtem_group„amount> 


C10 


B2 


01/16 


632. 10 






<item_flroup - reciplenUd> 


C10 


B20 


04/18 


6.3.2.11 






<dtern_subqroup_oount> 


CIO 


B21 


01/08 


6.3.2. 12 








- . . Element names tor - - - - 


-Protocol — 


Business 


SUe 


Reference 


Implemented - 


Remarks 


Rnanctal data functional group 


^SupporP 
(M/O/C) 


'Support'" 
(M/Bn) 




InFllStd 


cm— 




<financiaJ_data_fg> 






V 


6.4.1 






<function_header> [GS] 


M 


M 


V 


6.3.1.1 






<fg_securfty> [SIS] 


O 


B9 


V 


6.3.1.7 






<signature_ts> 


O 


B9 


V 


63.1.13.1 






<financiaLdata_Lsefe 


M 


M 


V 


6.4.1.1 






<ta_securitv_trcu!ef> [S1E1 


CI 


B9 


V 


6.3.1.8 






<fq_traiier> [GE] 


M 


M 


V 


6.3.1.2 






Table D.1 (continued) 


Element name for F0T: 


Protocol 


Business 


State 


Reference 


Implemented 


Remarks 


Financial data transaction set 


Support 
(M/O/C) 


Support 




InFUStd 






<financ(al„datajLset> 








6.4.1.1 






<trans_set_header> [STl 


M 


M 


V 


6.3.13 






<qeneraLFl l_extensions> [GFD] 


M 


M 


V 


6.3.2 






<finanaaLdata> 














<bin_seqment> [6IK] 


M 


M 


V 


6.35.7 






<trans_s8l_trailer> [SE] 


M 


M 


V 


6.3.1.4 
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Table D.1 (continued) 





Element names for BIN; 
Binary segment 


Protocol 
Support 
(M/O/C) 


Business 
Support 
(M/Bn) 


Sbe 


Reference 
InFHStd 


Implemented 
(Y/M) 


Remarks 




^)b\_segn>ent> 








6.3.1.11 








<length of binary_data> 


M 


M 


01/15 


6.3.1.11.1 








<blnary_data> 


M 


M 


01/10 15 - 
1 


63.1.11.2 








Table D.1 (continued) 


Element names for ST: 
Transaction set header 


Protocol 
Support 

(M/O/C) 


Business 
Support 
(M/Bn) 


Size 


Reference 
biRIStd 


Implemented 
(Y/N) 


Remarks 










63.1.3 






<trans_set_id> 


M 


M 


03/03 


63.1.3.1 






"FTS" 














■rr$- 














•ATS 














•QTS" 














-STS- 














-99T 














<trans sat_ control ntirn©er> 


M 


M 




63.1.3.2 








Element names for SE: — 

transaction set trader 


"Protocol — 
Support 
(M/O/C) 


-Business- 
Support 
<WBn> 


— Size— 


-Reference - 
biRIStd 


—tmptemented— 
(Y/N) 


—Remarks— 


<trans_set_trailer> 








63.1.4 






<no - of „tnctuded„segrTients> 


M 


M 


01A10 


63.1.4.1 






<trarts_S6t_contro}_nunib€r> 


M 


M 


04/09 


63.1.4.2 
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Table D.1 (continued) 



Data element names for SI E: 
Functional group security trailer 


Protocol 
Support 
(M/O/C) 


Buslnes 
s 

Support 
<WBn> 


Size 


Reference 
in FllStd 


implemented 
(Y7N) 


Remarks 


<fq_security traiter> 








6.3.1.8 






<messaqe auth_code> 


M 


M 


09/09 


6.3.1.8.1 








Element names for S2S: 
Transaction set security 


Protocol 
Support 
(WOK) 


Business 
Support 
(M/Bn) 


Size 


Reference 
(n FllStd 


Implemented 
(Y/K) 


Remarks 


<ts„security> 








6.3.1.9 






<security_S2S> 














<security_type> 


M 


M 


02/02 


6.3,1.9.1 






<security_orig_name> 


M 


M 


04/16 


6.3.1.9.2 






<secxirity_rectp_name> 


M 


M 


04/18 


63.1.9.3 






<authent_key_name> 


Ct 


B9 


01/16 


6.3.1.9.4 






<authent_se rv_code> 


CI 


B9 


01/01 


63.1.9.5 






<encryption_key_name> 


C11 


B9 


01/16 


6.3.1.9.6 






<encryptton__6erv_code> 


C11 


69 


01AB 


63.1.9.7 






<lenqtrt_of_data> 


C11 


B9 


01/18 


63.13.8 






<dnhia!ization_vGCtof> 


C11 


B9 


16/18 


63.1.9.9 











"Protocol 
Support 
(M/O/C) 


"Business" 
Support 
<M/Bn> 


^Stte— 


Reference 
tnFUStd 


Implemented 
(Y/N) 






Element names for S2E: 
Transaction set securtry trailer 


Remarks 


<fg_secumYJrailer> 








63.1.10 






<message aumentication_code> 


M 


M 


09/09 


83.1.10.1 







Element names for STS: 


Protocol 


Business 


Size 


Reference 


Implemented 


Remarks 


Signature transaction set 


Support 
(M/O/C) 


Support 
(M/Bn) 




aiFUStd 


(Y/N) 




<stgnature_ts> 








63.1.13.1 






<trans_set_header> IST1 


M 


M 


V 


6.3.1.3 






<skjnatune_data> [SIG] 


M 


M 


V 


6.3.1.13-2 






<securtty_oriq_name> 


M 


M 


04/16 


63.1.7.2 






<secartty_recip_name> 


M 


M 


04/16 


6.3.1.73 






<authem„alQOrtthm_ld> 


M 


M 


01/15 


63.1.133.1 






<key_and_or - block_size> 


C11 


B11 


01/01 


63.1.133.2 






<length_of_data> 


O 


B11 


01/18 


63.1.1333 






<sffjnstufB> 














<Hnary_seamerrt> [BIN] 


M 


M 


V 


63.1.11 






<trans_set_trailer> fSEl 


M 


M 


V 


63.1.4 
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Table D.1 (continued) 



Element names for GS: 


Support 


Bu&lnes 


Size 


Reference 


Implemented 


Remarks 


X12 functional group header 


(M/O/C) 


ft 

Support 

fun \ 




tn HI Std 


(Y/N) 




<function_header> 


• 


* 


V 


63.1.1 






<functionaLfiroupJd> 


M 


M 


02/02. 


63.1.1.1 






70 (Financial Data) 






* 


6.3.1.1.1 






71 (Item Views) 






- 


6.3.1.1.1 






FA (Functional Acks) 






- 


6.3.1.1.1 






72 (Application Acks) 








6.3.1.1.1 






73 (Query Request) 








6.3.1.1.1 






80 - 99 (Private) 








6.3.1.1.1 






<apo__senderJd> 


M 


M 


02/15 


63.1.12 






<app_reoelverJd> 


M 


M 


02/15 


63.1.1.3. 






<fg_date> 


M 


M 


06/06 


63.1.1.4 






<fo_tJme> 


M 


M 


04/06 


63.1.15 






<funct)on„contro)_nuntDer> 


M 


M 


01/09 


63.1.1 £ 






<standaitf> 


M 


M 


01A2 


63.1.1.7 






<versten> 


M 


M 


01/12 


63.1.13 








Element names for GE: 


Protocol 


Business 


Size 


Reference 


Imptemented 


Remarlcs 


Transaction set header 


Support 


Support 




tnFUStd 


(Y/H) 






_<IWO/C)_ 












<fcL_trafler> 








63.12 






<no__nduded„S0ts> 


M 


M 


01/10 


63.12.1 






<fiH^c6cn_.ccfrtro!_riunriber> 


M 


M 


0409 


6.3.122 







Element names for SIS: 


Protocol 


Business 


Size 


Reference 


Imptemented 


Remarks 


Functional group security 


Support 
(M/Q/C) 


Support 
<««n) 




tnFUStd 


(Y/N) 




<m_secumy> 








63.1.7 






<socurtiy_SxS> 














<securtty_type> 


M 


M 


02/02 


63.1.7.1 






<securrty_ortq_name> 


M 


M 


04/16 


63.1.72 






<security_redp_name> 


M 


M 


04/16 


63.1.73 






<authentJcey_name> 


C1 


B9 


01/16 


63.1.74 






<authenl.serv_.ccde> 


C1 


B9 


01/01 


63.1.73 






<enayptk>njcev„name> 


C11 


B9 


01/16 


63.1.73 






<encryplion_serv_ccde> 


C11 


B9 


01 m 


63.1.7.7 






<lengtruol.data> 


C11 


B9 


01/18 


63.1.73 






^nitiafi2Btton_vector> 


C11 


B9 


16/16 


63.1.73 
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Table D.I - Fll PICS pro-forma 



PlpmAnf mmae ff%r Cl| tttmfjftlllWI 
blCIIICIII ■ MUIMTO IUf » II 9liUVHUV| 

Indtidino ISA/1 EA seamenta 


Protocol 

fillDDOft 

(M/O/C) 


DH9UK99 


Size 


Reference 
In RIStd 


tmntentented 
(Y/N) 


Remarks 


<fii_structure> 




: 




622 






<inter_header> [ISA] 


M 


M 


: 


62.3 






<authorization> 


■ 


* 




6.2.3.1 






<authorization_qualifter> 


M 


M 


— 

02/02 


623.1.1 






<authortzationJnfo> 


M 


M 


10/10 


623.12 






<S6Cuttty> 


* 


* 


— : — 


6232 






<securfty_jqualffier> 


M 


M 


02/02 


6232.1 






<security_tnfo> 


M 


M 


10/10 


62J322 






<sender> 


- 


• 


• 


6.2.3.3 






onter_W_Qualifier> 


M 


M 


02/02 


6233.1 






<senderjd> 


M 


M 


15/15 


e a o a n 

623.32 






<receiver> 


" 


• 


• 


6.2.3.4 






4nter_id_quaUfier> 


M 


M 


02/02 


653.4.1 






<receivcr__id> 


M 


M 


15/15 


623.42 






<mterjtSatBj6me> 


• 


- 


- 


6235 






<inter_date> 


M 


M 


06/06 


6235.1 






^nt8r_ttrne> 


M 


M 


04/04 


62352 






<standarxi_version> 


* 


i iiT 


* 


623.6 






<standards_tdentifter> 


M 


M 


01/01 


623.6.1 






<version_M> 


M 


M 


05/05 


623.62 






. <j nter_controt> 


M 


M 


"09/09" 


623.7 






<ack_requested> 


M 


M 


01/01 


623.6 






n nt * — -** * 

<tesL,(natcaiof> 


ft J 

M 


M 


Ul/Ul 


c o o. a 






<subetement_seperator> 


M 


M 


01/01 


6.2.3.10 






<financta1_data_fp> 


0 


B4 


V 


6.4.1 






<ftem_vi8ws_Jg> 


O 


B5 


V 


6.42 






<(unctional_ackJs> 


o 


B6 


V 


6.3.1.12 






<apptication_jick_ i fc^ 


o 


B7 


V 


6.43 






<Query.requestsJa> 


0 


B8 


V 


6.4.4 






<rfnter_trafler> fiEAl 


M 


M 


V 


62.4 






<nurnber_groups> 


M 


M 


01/05 


62A1 






<i nter_control> 


M 


M 


09/09 


62.42 
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Bz/ shall be present only if <application_ack_diagnostic_code> indicates that 
contraints have been exceeded unless explicitly omitted in the Banking Practices 
Agreement. 

B2B shall be present if the <query_request_type> is other than a cancel request ("0"). 

B29 shall be present if the <query_request_type> is cancel request po") or restart 
request ("3"). 

B30 shall be present only if specified in BPA, and then shall be subject to the type of 
acknowledgment requested. 

shall be present if the <query_request_type> is retrieve request ("1"). 
B& shall be present when a snippet is requested. 
B33 shall be present to obsolete an outstanding query request. 
B34 shall be present to override the 300 second default 

B35 shall be present only to request a generic search on a specific value or range of 
values. 

NOTES • 

1 . Use of a Defautt value satisfies a Business Conditional usage requirement. 

2. If the Protocol Support column contains an O or C x . the Business Usage column should be Bx. 
3. Data elements composed of s^ 

subelement separator, K any subelement value is present This is further explained in 6.1.6. 

The Size column shall define the minimum and maximum number of characters (size) of the value for a 
data element when present The format is XXI YY where XX Is minimum size, and YY is maximum size. 
Values outside of the range shall be considered protocol violation. If the data element is composed of 
subelements, the size includes the sub-element separator characters. The data element delimiter (<gs>) 
and structure delimiter (<tr>) are not included in the size value. 

The size for subelement values does not include the subelement separator. However, subelement 
delimiters are included in the size of the parent data element because subelement separator(s) shall be 
present in a data element even though the value for the subelement may be absent. For example, when 
the data element consists of 3 sub-elements, the size value for XX and YY will be determined as the 
value, plus 2 characters for the 2 sub-element delimiters. 

NOTE - The size of a structure is the sum of the following components: 

- 1 character for each data element delimiter, plus, 

- 1 character for the structure terminator (<tt>), plus, 

- 2 or 3 characters for the length of the structure identifier (e.g., °GS° = 2 characters), 
plus, 

- size of the value for the actual data element 

The Reference column indicates the clause number in this standard where the element of protocol is 
defined. 

The Data element names column are organized by detail segments within transaction sets (i.e., X9's 
version of Transaction Sets), transaction sets within functional groups, and functional groups within the 
interchange. 
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B 5 shall be present if views of imaged items are in the interchange. 

B 6 shall be present if a Functional Acknowledgement is conveyed in the interchange. 

Br shall be present if an application acknowledgement is conveyed in the interchange. 

B a shall be present if a Query Requests Functional Group is present in the interchange. 

B9 shall be present only to specify or to convey security features or security 
mechanisms. 

Bio shall be present if the <query_requesUype> is restart request ("3"). 
Bn shall be present if the data element is required. 

B 12 shall be present if an acknowledgement Is requested, and the defaults are 
Inappropriate. 

B 13 shall be present when responding to query request, may be present for other 
transaction sets. 

B 14 shall be present for transaction sets containing item group, financial data, or query 
requests. 

B13 shall be present only to redirect an acknowledgement to a recipient other than the 
sender of this functional group. 

Bi6 shall be present when responding to a Query Request. 

Bu shall be present only to specify a limit for a generic criterion. 

Bie shall be present when <general_fiLextensions> are conveyed in the Financial 
Data Functional Group. 

B19 shall be present when <general_fiLertensions> are conveyed in the Item Group 
Transaction Set 

Ba) shall be present only in an Item Group Tranaction Set 

B21 shall be present in Item Views Functional Group unless explicitly omitted in Banking 
Practices Agreement 

B^ shall be present to cross reference to financial data, or query requests, if 
appropriate. 

B23 shall be present when cross referencing to another X9.46 transaction set, unless 
explicitly omitted by the Banking Practices Agreement 

B24 shall be present only to supplement the routing number of the financial institution by, 
or through whom, the item is payable. 

Bas shall be present if necessary to identify property the snippet 

Bas shall be present when <clipping_tnfo> are conveyed. 
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Ci 3 valid only if the <query_request_type> is search request ( a T). 

C, 4 valid only if the <query_request_type> is retrieve request ( a 1"). 

Cis valid only when <view_side_requested> is frontal view ("0") or rear view ("1 "). 

Cie valid only if the <query_request_type> is restart request ("3°). 

C17 valid only If <application_ack_diagnostlc_code> indicates that constraints have 
been exceeded HT)- 

Cie valid only if snippets are used. 

C 19 valid only if both snippet origin and offset are used. 

C20 valid only if snippet origin is used. 

C21 valid for any transaction set, shall be present when responding to a query request. 

C22 valid only when the acknowledgement is in response to a query request other than 
Query Cancel Request (V). 

The fact that a minimum length is specified for values, does not prevent Optional (or 
DEFAULTed) values from being entirely absent from an interchange with an actual length of zero. 
This descriptive convention is used to be consistent with X12 standards. 



The Business Usage column indicates support required by a financial institution's Business Practices 
Agreement which is external to this Standard: 

This column contains values Indicating the support required of business user applications by this standard. 
Its value expands upon the protocol support as required by the business community. The values shall be 
one of the following: 

M Mandatory. The value(s) for this data structure, data element value, or subelement value 
shall be present upon origination of the interchange, and shall be handled and made 
available to the receiving Fll-system-user on reception. Business usage is always mandatory 
when protocol support is mandatory. 

B x Business Conditional: A value for this data element or subelement is present or absent, 
under certain conditions, or as defined in the Banking Practices Agreement Specific 
predicates are Indicated with numbers (i.e. Bx) defined in the inline text. Use of a Default 
value satisfies a Business Conditional usage requirement 

Predicates for business usage conditions (Bx): 

B1 shall be present only if specified in Banking Practices Agreement 
B2 shall be present unless explicitly omitted in the Banking Practices Agreement. 
B3 shall be present only to override or supplement Banking Practices Agreement. 
B 4 shall be present if financial data is in the interchange. 
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0 Optional: 

On origination, this data structure (functional group, transaction set, data segment), data 
element, or subelement may be supported by the translator . When supported, it shall have 
a size and data type as specified 

On reception, Fll-translator shall support this data stnscture (functional group, transaction set, data 
segment), data element, or subelement as follows: 

If present this data structure (functional group, transaction set, data segment), data 
element, or subelement shall be handled by the receiving Fll-translator and shall be 
made available to the receiving Flhsystem-user. 

If not present, no error will be generated because of the absence of an optional data 
stmcture (functional group, transaction set, data segment), data element, or subelement 

NOTE - The fact that a minimum length is specified for values, does not prevent Optional (or 
DEFAULTed) values from being entirely absent from an interchange with an actual length of zero. This 
descriptive convention is used to be consistent with X12 standards. 

Cx Conditional: The Fit-translator's origination Support for this data structure, data element, or 
subelement is mandatory under certain conditions, and optional under all other conditions. 

The predicates V are indicated with numbers (Le. Cx) defined as follows: 

C t shall be supported if security at the present structural level is supported. 

C2 Conditional, valid only when the value of <trans_set_id> in the Transaction Set header 
is Item Group, Financial Data, or Query Request 

- — C3 - -required-when cross referencing between transaction sets, 



C 4 each shall be supported, but only one shall be present In acknowledgement 

C 5 if Query Requests Functional Group is supported, it too shall be supported. 
However, it shall only be present in a cancel request CO"), and no other data 
elements shall be included in the segment 

Ce shall be present only if signature data <slgnature_data> is present. 

C7 present only If requested to be acknowledged at the this level. If used, either the 
<8ubJect_ts_reUd>, <subjectjsd_refjd>, <subject.ftem.ref Jd>, 
<subject_ttem_viewjd>, or <subject_qrd Jd>, shall be present The presence of 
more than one of these shall be considered a protocol violation. 

The term valid is used in the predicates Cs - C23 to indicate that the applicability of a 
specific data element depends on the type of structure and function. It does not dictate the 
presence of the value in the interchange, and the data element is considered to be optional. 

Cs valid only if the <query_reque3t_type> is other than a cancel request ("0") 

Cq valid only in a Financial Data Functional Group 

C10 valid only in a Item Group Transaction Set 

Cn valid only if required by or applicable to the security mechanism utilized 

C Y 2 valid only if the <query_request_type> is cancel request fCTJor restart request 
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Annex D 

(informative) 

Financial image interchange protocol pro-forma for a 
Protocol Implementation Conformance Statement 



This annex summarizes the EDI interchange layout for the Financial Image Interchange protocol, and 
provides a pro-forma for users of this standard. In the context of standardization, the pro-forma is referred 
to as a Protocol Implementation Conformance Statement (PICS-pro-forma). This specific pro-forma is 
entitled Fll PICS pro-forma. The pro-forma may serve many functions for users, for example: 

1. vendors and service providers can use it to identify implementation support for optional aspects 
of this standard; or 

2. financial institutions and service providers can use it to indicate required support for procurement 
from their suppliers; or 

3. Readers of this standard have a summary of what the Financial Image Interchange protocol 
entails. 

Table D-1, contained in this annex, may be reproduced freely. All other aspects are covered by ANSI 
copyright infringement protection associated with this standard's publication. 

The Protocol Support column indicates support required by this standard: 

This column contains values indicating the ^ and X12, for these entries. 

-Support shall be verified as part of an implementation's conformance evaluationrThe values shalhte 
of the following: 

M Mandatory: 

On origination, tNs data structure (functional group, transaction set, data segment), data 
element's value, or subelement's value, shall be present on origination of the interchange, 
and shall comply with its defined syntax, e.g., size and data type as specWedAn error shall 
be generated if this data structure (functional group, transaction set, data segment), data 
element, or subelement, is absent 

On reception of the interchange, this data structure (functional group, transaction set, data 
segment), data element, or subelement shall be handled and made available to the receiving 
Fll-system-user. An error shall be generated if this data structure (functional group, transaction 
set, data segment), data element, or subelement, is absent 

- "Handle' means that the Fll-translator will recognize it, correctly parse its syntax, 
and validate only its size and data type. 

- 'Make Available" means that the Fll-translator will pass the data contents to the 
Fll-system-user. 



NOTE 1 - The mechanism by which an Fll-system-user provides the values (of non- 
translator generated data) to the Fll-translator is a heal implementation matter. 

NOTE 2 -An optional data-element may contain optional or mandatory subelements. If a 
subelement is mandatory it shall be present when the parent data element is present. 



177 



COPYRIGHT American National Standard* Institute 
Licensed by In format ion Handling Services 



XP008074623 



X9.46-1997 



C -3. 10.1. Transcoding considerations 

The following considerations should be evaluated if transcoding is used: 

a. Transcoding of images which have been compressed in one of the lossless compression 
algorithms will result in no loss of image quality when decompressed for use. Lossless 
compression algorithms include CCITT-G4, JBIG, and ABIC. 

b. Transcoding of images which have been compressed on one of the tossy compression 
algorithms may result in some degrading of image quality. A single transcoding has been 
reviewed by the X9B9 committee, and such a transcoding has been shown to be acceptable. 
That is, the resulting image degradation does not affect adversely the usability of the image. 
The only lossy compression algorithm supported by X9.46 is the JPEG Baseline compression 
algorithm. However, JPEG parameters can be set to achieve a nearly lossless quality with 
larger image sizes. The setting of the JPEG parameters is discussed in the JPEG standard. 

c. Since It is possible to interchange images compressed using algorithms not identified in tftfs 
standard, transcoding raster data compressed with such an algorithm has not been evaluated by 
X9, and risks associated with these transcodings shall be determined by the party banks. 
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Table C-1 - Business usage summary: BP A related conditions 


B1- Shall be present only if specified in BPA 


Element Name 


Reference 


Creation computer 


6.4.2.8.17 


View description 


6.4.2.8.18 


Scanner manufacturer name 


6.4.2.8.19 


Scanner model name 


6.4.2.8.20 


View capture software 


6.4.2.8.21 


Supplementary information 


6.4.3.1.11 


User data present indicator 


6.45.5.11 


Embedded header information 


6.4.2.8.16 


Search user data present Indicator 


6.4.4.358 




B2 - Shalt be present unless explicitly omitted In the Banking Practices Agreement 


Element Name 


Reference 


User data 


6.4.2.6 


Type of financial data 


6.3.2.7 


Item group amount 


6.35.10 


ISD subgroup amount 


6.45.3.6 


Hem amount 


6.45.6.7 


Image key 


6.45.5.9 


View side indicator 


6.45.8.5 


Resolution unit 


6.45.8.8 


Orientation 


6.45.8.13 




6:4££l4L4 


Subject transaction set reference identifier 


6.4.3.1.5 


Subject ISD reference identifier 


6.4.3.1.6 


Subject item reference identifier 


6.4.3.1.7 


Subject item view identifier 


6.4.3.1.8 


Subject ORD identifier 


6.4.3.1.9 


Number items matching criteria 


6.4.3.1.10 


Image keys matching criteria 


6.4.3.1.12 


Restart point indicator 


6.4.3.1.13 


Maximum matching views requested 


6.4.4.3.17 




B3 - Shall be present only to override or supplement Banking Practices Agreement 


Element Name 


Reference 


Acceptable compression Identifiers 


6.4.4.3.18 



C.3.9. Performance issues 

This section should specify any performance-related considerations. These include the number of 
imaged items required to be delivered in N time periods. 

C.3.10. Transcoding guidelines 

This section should specify the transcoding combinations which will be acceptable to the receiving 
institutions, establish use of intermediaries, if necessary, and determine any fees related to this process. 
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identified. The acceptance of the usage of any non-standard image parameter options should be dearty 
stipulated. 

C.3A ASCII or EBCDIC encodings 

This section should identify whether ASCII or EBCDIC encoding will be used to represent data in the 
Interchange. 

CJ3J5. Cross referencing 

In this section, parties should specify how extensively they will use cross referencing in interchange, and 
for what period(s) of time senders and receivers will maintain cross references. 

C.3.6. User data 

If parties intend to make use of any of the user data elements, the addendum should specify which user 
data elements will be present in interchanges, and which format(s), and encoding(s), will be used to 
structure the data. 

C3.7. Private values 

Many data elements allow for privatety defined values. The technical addendum should state the nature 
and extent of such usage between interchange partners. This section of the addendum also may be used 
to define more fully or to attach private meaning to relative data values (e.g., high priority, low priority). 

C.3.8. linage requirements 

"Thlssfectionshould otwerdetails^such as aa>ept^l^tiff^(s)) f oTfetransmi^i^if necessary, defihfttonof 
controls to limit each interchange to specific functional group types to ensure compliance with procedures 
defined in the standard, size of image bundles (sub groups), and image cash letters (groups), and 
acceptable Image views (i.e., Individual views partial view or snippets, or multiple views, if not covered 
elsewhere in the Banking Practices Agreement). 

C.3.8.1. Explicit protocol element support requirements 

The following table identifies informational elements that receivers would expect to receive, unless 
explicitly omitted in the BPA or Addendum, or would agree in the BPA or Addendum that the sender 
would provide explicitly. The table also provide cross references to location of description of these 
elements in the standard. 
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By:. 



fly- 



Title:. 



Xrtle:, 



Date:. 



.Date:. 



C.3. Technical addendum 

This section contains technical requirements or issues that participants in exchange should consider for 
inclusion in an Addendum to the BPA. 

C.3.1. Communications method 

Prior to performing Image interchange, each participant involved in the interchange should agree on the 
type of communications method to utilize. Normally, a BPA would cover agreements on communications 
methods between senders, receivers, and intermediate sites. Examples of communications methods 
include, but are not limited to, the following: 

a. Teleprocessing methods; Links, network end point addresses, speed, data transfer protocols, 
eta should be defined for teleprocessing methods; 

b. Hard media: Hard Media requires physical transportation from one site to another. 
Consideration should be given to the mode of transportation, the delivery time, and the kind of 



-^a^Goritingency^lanning^ 

references to business resumption procedures, and should include disaster site information and 
designated alternative service providers; 

d. Value added networks; Value added network specific infomtation for communications. 
Media to be interchanged 

When hard media is to be utilized, the type of media should be specified within the BPA. Examples of 
media type include, but are not limited to, the following types: 

a Tape 

1) 9 Track (6250 or1 600) 

2) 3480 Cartridge (18 or 36 track) 

3) 1/4" Cartridge 

4) DAT 

b. Optical Disk 

1) Write Once Read May (WORM) 

2) Magneto Optical (MO) 

3) Compact Disk (CDROM) 

C.3.3. Acceptable compression algorithm and imaging parameter options 

This part of the addendum would identify the compression algorithm and imaging parameters which the 
paying bank is willing to accept as part of the interbank image interchange. It would clearly identify spatial 
scan densities, gray levels, and description the compression algorithm used (see table in 4.11). All 
required review elements, which should clearly be available for each view, should be specifically 



media; 
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attached hereto. Paying bank shall notify presenting bank [within of receipt] if 

retransmission of an image(s) is necessary because of poor quality or other reasons. 

6. Return and notice of nonpayment. 

(a) Upon receipt of an instruction to return from the paying bank by 5:00 p.m. local time of the 

presenting bank on a business day in accordance with this agreement the presenting bank shall 
retrieve the eligible check, add the reason for return, and return the check expeditiously by the 
presenting bank's midnight deadline. The instruction to return shall contain the following 

information:, I I an image of the check J and the reason for return, and the 

instruction shall be considered a notice In lieu of return under Regulation CC, section 229.30(f). 

The instruction should include Information that permits retrieval of the check, and the parties may also wish to 
require return of an Image received by the paying bank. 

(b) Paying bank warrants to presenting bank that an instruction to return relates to an eligible check, 

including an eligible check that is payable through paying bank, presented by presenting bank 
no eariier than the paying bank's banking day next prior to the business day of receipt of the 
instruction to return by the presenting bank. 

(c) Presenting bank shall give notice of nonpayment to the depositary bank in accordance with 

Regulation CC, section 229.33, for an eligible check in the amount of $2500. or more. The nonce 
must be received by 4:00 p.m. local time of the depositary bank on the business day following 
the business day of receipt of the paying bank's instruction to return by the presenting bank. 

7. Transmission and security . 

(a) The parties shall transmit MICR line data, images, requests, instructions, and other 
communications in accordance with the te chnica l Addendum attached hereto. 

8* Fees. 

(a) The parlies agree that the fees [set forth in the Addendum] will apply under this agreement 

9. Liability, 

(a) Each party shall be liable under this agreement only for its own lack of good faith or failure to 

exercise ordinary care as provided in Regulation CC, section 229.38. Each party shall be liable 
for breach of warranty under this agreement as provided in Regulation CC, section 229.34. 

(b) The parties agree to adhere to the Rules on Interbank Compensation of the National Council for 

Uniform Interest Compensation regarding compensation claims not covered by Regulation CC. 

(c) Disputes between the parties shall be submitted to binding arbitration under the rules of the 

American Arbitration Association. No arbitration proceeding shall be brought under this 
agreement by a party against the other party more than one calendar year after the cause of 
action accrues. 

(d) This agreement is a truncation agreement as provided in Regulation CC, section 229.36(c), and 

an agreement for electronic presentment as provided in the Uniform Commercial Code (1990), 
section 4-1 10. This agreement is also an agreement as provided in Regulation CC, section 
229.37, and Uniform Commercial Code, section 4-103, and a banking practices agreement as 
provided in X9.46, Annex C. 

10. Termination. 

(a) This agreement may be terminated by written notice by one party to the other effective [five (S)J 
business days after receipt of the notice, or at a later date specified in the notice. Termination 
shall not affect a party's obligations under this agreement (including retention, unless otherwise 
agreed) with respect to eligible checks presented on a day prior to termination day. 

Presenting bankiPaying bank: 
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10) for adjustments of $ or mora, on the next business day; 

(ii) for adjustments under $ received less than business days after 

settlement, within business days; and 

(iii) for adjustments under $ received or more business days after 

settlement, within business days.] 

The parties shoufd agree on procedures for submission and settlement of adjustments. 

4. Retention of eligible checks. 

(a) Presenting bank shall retain eligible checks for [sixty (60)] calendar days from the date of 
presentment, or until returned upon the instruction by the paying bank. 

The checks must be available for return upon instruction by the paying bank, and may be needed during the 
usuai customer inquiry period of a statement cycle plus a reasonable time. Local law of each bank should be 
consulted. 

(b) Presenting bank shall send to paying bank [by / an eligible check within 

of receipt of a proper request, which shall include . 

5. Retention and availability of images. 

(a) Presenting bank shall retain an image of each eligible check [for a period of [seven (7)] calendar 
years from the date of presentment, or, if the check is returned by the presenting bank upon 

Instruction by the paying bank, for a period of calendar days from the date of 

presentment] [until paying bank has acknowledged receipt of the image from presenting bank as 
provided In section 5(e)]. 

The parties, should determine, whether the presenting or the paying bank win perform storage of images. 
-Local law of both parties should bo consulted. 

(b) Presenting bank shall transmit to paying bank [a snippet (as defined in X9.46)of]the 

image of an eTtgible check: 

[(i)] within [one-half hour] of receipt of a proper request from the paying bank if received by 
p.m. local time of the presenting bank on the business day of presentment; 

[or (ii within [four hours] of receipt of a proper request if received after such time on the 
business day of presentment but within five (5) business days from the date of presentment 

on (Hi within [twenty-four (24) hours] of receipt of a proper request if received after five (5) 
business days but within seven (7) calendar years from the date of presentment] 

The parties should provide for transmission of individual images, or snippets thereof, upon request within 
certain times. Subsections (b)(ii) and (iii) may not apply if images have been transmitted to the paying bank 
for storage, and receipt has been acknowledged (see next subsection). The parties also may wish to provide 
for regular transmission of certain predefined images. 

[(c) Presenting bank shall transmit to the paying bank images of all eligible checks presented on a 

day by p.m. local time of the paying bank on [that day] [the business day 

following the day of presentment] Paying bank shall examine images received from the 
presenting bank for storage, and either acknowledge receipt or request retransmission. 
Presenting bank is relieved of responsibility for all images whose receipt is acknowledged by 
paying bank.] 

This paragraph should be used if the parties wish to provide for transmission of all images to the paying bank 
for storage on a regular schedule, which should take into consideration the need for images on demand to 
assist in the decision to pay or return. 

[(d)] A proper request for an image of a specific eligible check shall include 

and shall be transmitted in accordance with this agreement The transmission of images by the 
presenting bank shall comply with this agreement with X9.46, and with the technical Addendum 
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The parties should state whether electronic presentment of eligible checks is optional to the presenting bank 
under this agreement, when transmissions are permitted each day and whether reject repair is required. If 
reject repair is not required, the agreement should permit normal presentment of the original check. 

(b) Paying bank agrees that presentment of an eligible check is considered to occur upon delivery 
to it or its designated agent on a banking day for paying bank of MICR line data in accordance 
with this agreement The paying bank waives any right to exhibition of the eligible check except 
as provided in this agreement 

(c) By transmitting MICR line data from an eligible check to paying bank, presenting bank warrants, 
In addition to other warranties imposed by law, that: 

(I) the presentment complies with this agreement; 

fti) the MICR line data transmitted accurately represents the MICR line data on the eligible 
check; 

(tii) presenting bank is capable of retaining and transmitting an image of the eligible check In 
accordance with this agreement, and 

(iv) presenting bank will not present the original eligible check to paying bank unless specifically 
requested by paying bank. 

(d) Presenting bank has no responsibility for determining whether an eligible check Is property 
payable, including whether 

fi) the check bears the authorized signature of the drawer or any other signature; 

fti) the check is stale dated or postdated; or 

(tii) the check bears a legend restricting payment. 

~(e)~By&ttwhgihtotftls agreementTpayingb^rtk warrants to presentih^t^irtl^t^'isle§illy~ 
authorized to cany out the terms of this agreement, and has obtained any agreement of the 
drawer of an eligible check, the payor of an eligible check that is payable through paying bank, a 
regulatory body, or other person, that is necessary for carrying out the terms of this agreement 

3. Settlement 

(a) Paying bank shall settle for eligible checks presented under this agreement in accordance with 
Regulation CC, section 229.36(f), by [Fedwire funds transfer to presenting bank's account at the 

Federal Reserve Bank of / [debit/credit to presenting/paying bank's account on 

the books of paying/presenting bank] [other method agreed to by the parties]. If an eligible check 
is presented after 8:00 am local time of paying bank, but before [2:00 p.m. or later ledger cutoff] 
that business day, the check is considered presented that banking day of paying bank, and 
paying bank shall settle by Fedwire funds transfer to such account by 1 1.-00 am Eastern Time 
the next banking day for paying bank. 

The second sentence provides for a time of settlement on the next day for checks presented after 8.-00 a.m. 
that is earlier than the dose of Fedwire that next day, but later than midnight on the day of presentment. 
Checks presented after the cut-off hour specified would be considered presented the next banking day and 
settled by the dose of Fedwire that next day. 

(b) Presenting bank shall settle for eligible checks for which an instruction to return is received by 
presenting bank by [5:00 p.m. local time of presenting bank] by means of [Fedwire funds transfer 

to paying bank's account at the Federal Reserve Bank of ] [debit/credit to 

paying/presenting bank's account on the books of presenting/paying bank] [other method agreed 
to by the parties] by the close of Fedwire on the banking day of receipt of the instruction to 
return. 

(c) The parties agree to settle adjustment requests by [Fedwire funds transfer to their respective 
Reserve bank accounts] [entries to their respective correspondent accounts] [other method 
agreed to by the parties] as follows: 
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Banking Practices Agreement 
for 

Electronic Check Presentment With Image Capability 
[Proforma] 



This AGREEMENT between , of , and 

t of provides for electronic 

presentment of eligible checks [between the parties] [by the presenting bank to the paying bank,] by 
transmission of MICR line data and the retention of images of the checks by the presenting bank and 
transmission of the images on request to the paying bank. 

The agreement should state whether each party or only one party may present Checks under this agreement 
See sections 1(0 and (g). 

1. Definitions. _ 

(a) Unless otherwise defined, the terms have the meanings set forth or refened to in Regulation CC 
(12 CFR Part 229). 

(b) " X9.-° means the standard adopted by the Accredited Standards Committee on Financial 
Services of the American National Standards institute as amended from time to time. 

(c) "Eligible check" means a check (i) payable by, at, or through the paying bank; [and] (ii) that 
contains a "9 m in position 44 of the MICR line when received for collection by the presenting 
bank; [and (iii) that is in an amount of $ or less]. , 

[Agreement (c) applies to eligible checks that the presenting bank elects to present electronically under this 
agreement] 

The parties may wish to set a dollar cutoff tor eligible checks to avoid truncation of large dollar checks. The 
last bracketed sentence should be adopted if the presenting bank has an option to present eligible checks In 
their paper form. See section 2(a). 

(d) "Image" means an image of an eligible check that conforms with the requirements of X9.46 and 
that is of a quality [acceptable to paying bank as determined by testing with presenting bank]. 
The term includes the front and back of an eligible check unless a portion thereof is specified in 
this agreement 

The parties should agree on what quality of image is acceptable. 

(e) "MICR line data" means the information Q preprinted, or postencoded on an eligible check in 

accordance with X9. 13. 

The parties may want to specify only a portion of the MICR line for transmission. 

(f) "Paying bank" means [a party to thb agreement] [ /, that is the 

paying bank as defined in Regulation CC, section 2292(z) f with respect to an eligible check. 

(g) "Presenting bank" means [a party to this agreement] [ I that presents an 
eligible check under this agreement 

2. Presentment 

(a) Presenting bank [shall] [may] present eligible checks to paying bank by transmitting the MICR 

line data to paying bank [between and on each banking day] in the 

format set forth in [ X9.37] in accordance with this agreement Presenting bank [shall] [is not 
required to] [shall not] repair or reenter MICR line data with respect to an eligible check that 
rejects from automated processing. 
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C.1 .3. Returns and LDRINs 

In the near future, the paper items will be the basis for returns. In the longer term, workable procedures 
for the use of imaged returns may emerge. 

- Return requests: The paying bank should notify the presenting bank of returns by 5:00 p.m. on 
the first business day after the day of presentment These requests would cover all items, large 
or small, dollar. 

Large dollar return notifications: The presenting bank must notify the BOFD of large dollar 
returns fie. $2,500 and above) by 4:00 p.m. ET the following day (ie. the second business day 
after the day of original presentment). 

Returns: The presenting bank, acting as a returning bank, has until midnight of the following 
day to initiate returns to the BOFD (le. midnight of the second business day after the day of 
original presentment). 

Settlement: Settlement for returns follows the current procedures under Reg. CC and the UCC. 
C.1.4. Pricing 

The presenting and paying bank would determine the existence and level of fees for provision of images 
or return sen/ices and cover any such arrangements in the BPA. 



C.2. Banking practices agreement pro forma 

The following text establishes a pro forma template for the creation of banking practices agreements. This 
~pm~forma~<k^^ 

two-way electronic presentment of checks supplemented by images of the checks. 
This pro forma provides for : 

1. Electronic presentment by transmission of MICR line data under X9.37 or other acceptable 
format, and subsequent transmission of images under X9.46 on per-check, or standing request 
Checks eligible for presentment under this agreement are designated by a 9 in position 44 of the 
MICR line. 

2. Presentment by 8:00 a.m. under the Regulation CC "same-day settlement 0 rule, and either long- 
term or temporary storage of the images by the presenting bank. 

The pro forma contemplates that two banks could either simply make the choices set forth below, or vary 
and supplement the provisions in this form. Bank counsel should be consulted. Bracketed "[ ]" language is 
optional; italicized language is explanatory, and is not intended to be retained in the agreement. 



♦♦♦♦♦♦♦♦ 
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b.) Long-term goal: a presenting bank should store the paper checks until the normal return 
cycle is complete, approximately five days, 

C.1 .2.2. Scenario II: Temporary storage of Images by presenter (Scenarios A & B) 

Within Scenario It, there are two subordinate scenarios, A and B, as follows: 

A. ) The paying bank wants the presenting bank to provide all images the same day as the electronic 
presentment. Provision of these images generally would require transmission, although hard media might 
be an option in some cases. 

• Availability of selected image, in the manner specified by the BPA: 

- Priority: The presenting bank must be able to supply images upon request within one half 
hour for items presented that business day. 

• image storage: The presenting bank stores images until it receives acknowledgement of bulk 
image receipt, and release of responsibility, by the paying bank. The paying bank then assumes 
responsibility for maintenance of images in a manner that will sustain the quality for seven years 
(or other local law). 

• Paper storage: 

a. ) Current: a presenting bank should store the checks for sixty days, a period covering the 

statement cycle and a reasonable period for customer requests of items thereafter. 

b. ) Long-term goal: a presenting bank should store the paper checks until the normal return 

cycle is complete. 

B. VThe payor wants to receive all check images, but rwt the same ^ 

items. Generally, the presenting bank would supply these on hard media, although transmission would be 
an option. 



• Availability of selected images, in the manner specified by the BPA: 

- Priority: The presenting bank must be able to supply images upon request within one half 
hour for items presented that business day. 

- Short-term: a presenting bank should provide an image of an item presented within the last 
five business days, within four hours (during time frame specified by the BPA) of receipt of 
the request for an image from the paying bank. 

• Preefined recurring Images: A presenting bank will provide images, based on parameters 
predefined by the paying bank, every business day that it presents items electronically, 
according to the terms of the BPA. 

• Image storage: The presenting bank stores images until it receives acknowledgment of bulk 
image receipt, and release of responsibility, by the paying bank. Payor then assumes 
responsibility for maintenance of images in a manner that will sustain the quality for seven years 
(or other local law). 

• Paper storage: 

a. ) Current: a presenting bank should store the checks for sixty days, a period covering the 

statement cycle and a reasonable period for customer requests of items thereafter. 

b. ) Long-term goal: a presenting bank should store the paper checks until the normal return 

cycle is complete. 
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C.1 .1 .2. Presentment and settlement times 

If the presenting bank presents items electronically by 8:00 a.m. (local), the paying bank will pay for these 
items in same day funds by the close of Fedwire. This parallelism with Same-Day Settlement (SDS) is 
necessary to provide terms at least as good as those 

If a presenting bank presents items electronically between 6:00 a.m. and 2:00 p.m. (local), or later ledger 
cut-off, the paying bank would pay for those items in good funds by 1 1 :00 am. ET the following day. The 
purpose of this presentment time is to provide consistency with the treatment of items that miss the 8:00 
am (local) SDS presentment deadline. For those items, the return clock starts the same day and 
payment (but not in same-day funds) must take place by midnight of the same day. 



C.1 .2. Checks and images: storage, availability, and usability 

Paying banks may choose different scenarios regarding provision of images by presenting banks that 
affect both storage times for paper checks and turnaround times for image requests. Participants in 
exchange also may want to include in the BPA specific conditions and timeframes relevant to possible 
resends of images that might be necessary, as a result of, for example, unacceptable quality or technical 
problems. Additionally, the timeframe and method of delivery of paper, if requested, should be clearly 
defined. 2 

C.1 .2/1. Scenario I: Long-term storage of images by presenting bank 

The paying bank wants the presenting bank to store the images it captures on Items presented 
. etectronicallyJoJhe.paying.bank. : ! i '. 

• Image storage: The presenting bank stores images in a manner that will sustain the quality of 
the image for seven years (or longer, if required by local law applicable to collecting, or payor, 
bank). 

• Availability of selected Images, in the manner specified by the BPA: 

- Priority: a presenting bank should provide an image of an Hem presented that business day, 
within one half hour of the request for the image by the paying bank. 

- Short-term: a presenting bank should provide an image of an Hem presented within the last 
five business days, within four hours (during time frame specified by the BPA) of receipt of 
the request for an image from the paying bank. 

- Long-term: a presenting bank should provide an image of an Hem within twenty-four hours 
of receipt of the request from the paying bank, H H presented the Hem electronically during 
the time period spanning seven (or more) years to six business days ago. 

• Availability of predefined recurring Images: A presenting bank will provide images, based on 
parameters predefined by the paying bank, every business day that H presents Hems 
electronically according to the terms of the BPA. 

• Paper storage: The presenting bank needs to pull Hems to return timely to the bank of first 
deposit (if collector is not the BOFD) upon receipt of return requests from the paying bank. 

a.) Current: a presenting bank should store the checks for sixty days, a period covering the 
statement cycle and a reasonable period for customer requests of Hems thereafter 



tn all the following examples, an agent d the presenting bank could perform tmage capture and archive services on Its behalf. 
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Annex C 

(informative) 

Banking practices agreement 



This annex provides information for use in the public domain and is not part of the standard. 

A Banking Practices Agreement (BPA) Is an agreement between parties who wish to participate in 
Interbank Image Interchange. This annex comprises three sections: (1) a section providing description 
of a suggested framework to support interbank image interchange covering Presentment and Settlement, 
Storage and Availability of Checks and Images, Returns and Large Dollar Return Item Notification, and 
Pricing. This framework draws on existing regulations, such as the Uniform Commercial Code (UCC) and 
Regulation CC (Federal Reserve), as a base; (2) a section presenting this framework in legal 
terminology, with specific references to existing regulation, as a model, or proforma for that part of the 
agreement dealing with the above clearing issues; and (3) a section containing technical issues or 
requirements that a BPA should address to support the Finance Image Interchange standard (see clause 
4 for Summary of Standard Required Elements). 



C.1 . Suggested framework for image-based electronic check presentment 

The purpose of a suggested framework for image based electronic check presentment is to facilitate the 
development of such presentment by providing a set of guidelines. These guidelines include what paying 
and presenting banks normally would expect from each other. 



The Banking Practices Agreement, which a presenter and a payor would establish prior to actual 
presentment of image-based electronic checks, would be the logical vehicle for agreeing with the 
specifics of the suggested framework, or for varying such specifics by agreement Whether the suggested 
terms of the proforma are accepted as is, or are varied by agreement, both parties to the agreement should 
consult bank counsel as part of the negotiation process. 

C.1 .1 . Presentment and settlement 

C.1 .1.1. Definition 

Presentment by a presenting bank occurs upon the receipt of an electronic transmission of the check 
MICR line and related information in the ASC standard format (X9.37), or other acceptable format, by the 
paying bank whose customer placed the 9 in position 44 of the MICR line. The presenting bank warrants 
to the paying bank that it has captured an image of acceptable quality of each item presented. This 
warranty provides insurance for the paying bank against a presenting bank's presenting items that have 
no images, or unusable images. A presenting bank would present electronically all items it processes 
drawn on that paying bank and identified by a 9, not just on selected items, unless varied by agreement 
Such presentment depends upon the prior existence of a Banking Practices Agreement (BPA) between 
the presenting and the paying banks. 1 



The BPA also could enable two Institutions to perform image-based exchange on {terns that do not have a 9 In position 44 of the 
MICR tine. 
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B.4 JBIG 

Single progression sequential JBIG coding specified in CCfTT T.82 (reference [4] in clause 2) shall be 
used. As defined in annex A of CCITT T.82, the maximum support for the JBIG parameter D is zero, the 
maximum support JBIG parameter 1^ is Y D , and no support is required for the parameters HLTOLO, SEQ, 
TPDON, DPON. DPPRIV, and DPLAST. The rest of the parameters are defined in table A-1 of annex A 
in CCITT T.82. 

BJS ABIC 

The ABIC coding with the standard model/adapter/coder (MAC), defined in the IBM Journal of Research 
and Development, Vol. 32, No.6, pp. 717-795, November, 1988, shall be used with additional constraints 
as follows:. 

In the compressed state, all images must be padded to a width which is a multiple of eight pixels. The 
padding bits are normally zero bits (O's). These padding bits shall not be counted as part of the 
image width parameter. 

For gray-scale images, pixel values shall be Gray coded as defined by F. Gray in US Patent 
2632058. 

For a given binary presentation of a number b = (b nf ... y b lf b 0 ), the corresponding Gray code is 

8 = (8* g x ,g 0 ), where g n =b n and g k =b M ®b k for 

k=0,t,... f n-f, and where 1©0=0©1 = 1, 101 = 0, and oeo=0. 

After Gray coding, the gray-scale bit planes shall be concatenated into a single virtual binary image in 
such an order: the most significant bit plane first 
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Annex B 

(normative) 

Description of compression algorithms 

This annex specifies compression algorithms applicable to this standard. 

B.1 Uncompressed 

Each pixel of uncompressed image shall be encoded as standard binary numbers. Images shall be 
bitonai or gray-scale. This standard only supports the following pixel precisions; one bit per pixel, two bits 
per pixel, four bits per pixel, six bits per pixel, and eight bits per pixel. 

For bitonai uncompressed images, eight pixels shall be packed into one byte in the order of the most 
significant bit first. 

For gray-scale images, the packing of pixels into bytes shall occur as follows: 

• Uncompressed data shall be packed with the most significant bit of a pixel into the most 
significant bit of a byte, or of the remaining unfilled portion of the byte. 

• For images with the pixel precision of two bits per pixel, four pixels shall be packed into one byte. 

• For images with the pixel precision of four bits per pixel, two pixels shall be packed into one byte. 

• For images with the pixel precision of six bits per pixel, one pixel shall be packed into one byte 
with the low two bits of the byte being zero-filled to complete each byte. 

Each line of an uncompressed image shall be padded with zeros such that the following line starts on a 
byte-boundaiyrThe-padding bits of the last byte on each l^ 
width parameter. 



B.2 CCITT T.6 Compression 

The base facsimile coding scheme specified in CCmr T.6 (reference [6] in clause 2) shall be used. 
Optional facsimile coding schemes shall not be used. 



B.3 JPEG Baseline (JPEG Interchange Format) 

JPEG Baseline with JPEG interchange format specified in CCITT T.81 (reference [5] in clause 2) shall be 
used. Images compressed by this standard shall consist of only one component (gray-scale). 

JPEG Baseline compression requires that, before performing compression, all pixels of an uncompressed 
grayscale image shall be packed into bytes as follows: 

Uncompressed data shall be packed with the most significant bit of a pixel into the most significant bit 
of a byte. 

One pixel shall be packed into one byte with the low, unused bits of the byte being zero-filled to 
complete each byte. 
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<cce_bu$ne$s_date_range> ::= [<ece_busness.date„start>]<us>[<ece_bu8ness_date.end>] 

<ece_busness_date_start> (08/08) ::= <x9_date> 
<ece_b usness_date_ end> (08/D8) <x9.date> 

<«ce_seq_number_range> ::= [<ece_seo.number_8tart>]<us>[<ece H seq_number.end>] 

<ece_seq_number_start> (01/15) ::= <string> 

<ece_seq_number_end> (01 A 5) ::= <string> 

<ece_cyde_number_range> ::= [<ece_cyc!e_n umbor_start>] 
<us>{<ece_cycle_nurnber_end>] 

<ece_cycle_number_start> (01/02) <string > 
<ece_cycte_number_end> (01/02) ::= <string > 

<amount_range> ::= [<amount_start>]<us>[<amount_end>] 

<amount_start> (01/12) ::= <numerio 

<amounL.end> (01/12) ::= <numerio 

<accounl_number__range> [<account_number_etart>}<us>[<account_ number_end>] 

<account_number_start> (01/18) ::= <8tring> 
<accouitt_number_end> (01/18)::= <string> 

<ftem_serial_fiumber_range> ::= [<Kem_seriaLmimber_ start>] 
<us>{<item__serial_numbef_end>] 

<item_seriaLnumber_start> (01/1 0) <string> 
<&enuserial_number__end> (01/10) ::= <string> 

<privateJocator_range> :;= [<privateJocator_start>J<us>{<prfvateJocator_.end>] 

<prtvateJocatof_q tart> (01/B0) :: = <string> 
_ <prtvate^tocator^end>(01/80)-;:s <string> — _ '— 



<iBstart_point_lndicator><01/v) ::= <string> 

<search.user„dal^resent.indicator>(01/D1) ::= <sudpl_absent> I <sudpLpresent> 

<sudpLabsent> ::= "0" — [DEFAULT] 

<sudpLpresent> ::= "1 " 

- END of protocol 

end -FIIP Interchange Syntax 
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<no_sec_reqd> 
<digltaLslgn_only> 
<macd_only> 
<encryption_only> 
<cncryption_digMaLslgn_only> 
<encryption_and_macd_only> 



= "00- --DEFAULT 
= "10" 
:= "20° 
:= -01° 

::="11" 

"21" 



- Search/list and Retrieval data elements 

<scate_8ize_requested>(01/03) ::= <numerio - represents a percentage (%) 

<respon$e_media>(01/Q3) <etectron ic_f ormat> I <lape> I <optlca!_disk> I <diskette> I 

<paper_copy_of_Kem> 1 <originalJtem> I <reserved_for.x9_meida> I <user_defined_media> 



<electronic_format> 
<tape> 

<opticaLdisk> 
<diskette> 

<paper_copy_of Jtem> 
<orig1nalJtem> 
<reserved_for _x9_medla> 
<user_defined„media> 



•s "0° - DEFAULT 

:="1" 

:= "2" 

:=*3" 

:a "4" 

:= "5* 

:= "6° I _ I "799" 
:= °BO0 m \ .J M 999" 



<transport^medla__requested>{01A)2) <elec_comjinlo I <hand_courien> I <ovemight_maft> I 

<regutar_mail> I <fax> I <private_transport> I <reserve4_for_x9Jtrasp_media> 



<elec_com_Hnk> 
^hand_courler> 
<ovemight_maJk> 
<regutar_malt> 

_<fax> ....... 

~<private_transport>- 



:= -0" - DEFAULT 

"1" 
» B 2" 
:= "3" 

:=5^4" 



<reserved Jor_x9_trasp_media>: := "10"l...l"99" 
<processlng_priority><01 /01 ) ::= <iow> I <medium> I <high> I <user_defined_priority> 



<Jow> 
<medium> 
<high> 

<user_defined_priority> 



"1" 
"5" 
"9" 



"2" I "Z" I M 4" I "6T I T" I *8" 
<retain.custodyJndicator>(01/D1)::o <retain_custody> I <pass_custody> 
<retatn_custody> :;= a 0" -DEFAULT 



<pass_custody> 



"1" 



::= <frontal_view> I <rear_vtew> I 



<v1ew_side_requested>(01A)1) 
<frontaJ__and._rear_v!ew> 

<frontal_view> ::= **0" - DEFAULT 

<rear_view> ::= "1" 

<fronta]_aiid_rear_vtew> :s= "2" 

<vlew_snippet_region>{01 /31 ) ::= <snippet_name> I <snlppet_detailJnfo> 

<absoletes_query_requestJd>(34&2) [ <te_.ref Jd> ] [<us> <qrdjd> ] 

<max_lapso_tiine><01 /D6) ::= <Jtumerio - expressed in seconds 

<max_mmching_vtews_reqd>{01/06) <mimerte> 

<acceptable_compressionJds> ::= <view_compression_algo_ld> { <usxvlew_compresslon_algo_ld> } 
<payor_banK_m>(09/D9) <routing _number> 

- Search and list only criteria 
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[ <amount_range> ] <gs> 

[ <account_number_.range> ] <gs> 

[ <ftem_senaLnumber_rango ] <gs> 

[ <private Jocatoi_range> ] <gs> 

[ <restart_point_lndicator> ] <gs> 

[ <search_usef_data_presentJndicator> ] <tr> 

- Query request type 

<q uery_req uest_type> (01/02) ::= <cancel_request> ! <xetrievaJ_request> I <search_request> I 
<restart_request> I <reserved_for_X9_types> I <private_request_types> 

<cancel_request> ::= w o° . 

::= "2" 
::= *3" 

::= "4- 1 ... I "50" 
::= "5ri^l"99' 



<relrievaLrequest> 
<search_request> 
<restart_request> 
<reserved_forJ(9_types> 
<private_request_types> 



- Query Request Data segment identifier 

<qrd_ld> (1 a/350) ::= <ts_ref_id> M ."<1ocaLvalue> 

- Cancel criteria for an outstanding query request 
<subject__re1Jd>(22/B0)::= <ref Jd_typexusxretjd_value> 

<rcfJd_typo(01A)1) ::= <ts_refjd> I <qrd Jd> I <lsd_refjd> I <item.reffjd> 
<ts_ref_id> ::= "0 W 

<qrdjd> 

<isd_ief_id> ::= "2" 

<item_ref Jd> "3" __ 



<rof Jd_vaIue>(2Q/S8)::= <ts_refjd> I <qrdjd> I <lsd.refjd> ! <hem_refjd> 

- Retrieval imaged item criteria 

<retrievaljmage_lcey>{34/v) :t= <tmage_key>[<usximage_key>] 

- Operational data 

<colorJndicator>(0l/D2) ::= <bw_or_gray_scaJe> I <bw_only>1 

<gray_scale_onty> I <bw_and_gray_scalo I <x9_use> I <private_use> 

<bw_of_gray_scaJe> ::= "0 a 

<bw_only> ::= "I" 

<gray_scaIe_on1y> ::= "2" 
<bw_and_gray_scale> "3° 

<x9_use> ::o "4"l ~ I "60" 

<prfvate_use> ::= -51" I I "99 w 



<outputjypejequested><01/01) ::= <ftemJnfb_only> I <itemJnfo_and_user_data> I 
<ftemJnfo_andJtem _vtews> I <ttem Jnfo_user_data_and_views> I <bnage.keys.onty> I 
<vtews_ofJterruonly> 

<jtem_lnfo_onty> ::= B 0" 

<ftemJnfo_and_.user.data> M 1" 
<ftemJnfo_and Jtem _vtews> ::= m 2 n 
<itemJnfo_user_data_and_view3> "3" 
<image_keys_only> ::= "4° 

<vfews_of Jtem_only> "5" 

<secured_results.request.indicator> (02/02)::= <no_sec_reqd> I <dlgrtal_9ign_only> I <macd_on!y> I 
<encryption_onty> I <encryption_dig!taLsign_only> I <encryption_and_macd_only> 
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<query_requests_fg> ::= 
<fg_headcr> - value for <functionaf_groupJd> = *73* 

I <fg_securtty_header> ] -for data integrity check the entire FG 
[ <slgnature_ts> ] - for authentication of the originator of the entire FG 

- FifP query request set transaction sets 
{ <query_req uest_ts> ) 

[ <fg_security_trailer> ] - for data integrity check of the §ntim FG 

- Functional Group Traitor 
<fg_traiier> 

- Query transaction set definition used for transmitting search, retreive, and cancel requests 

<query_request_ts> 
<trans_set_header> - value for <trans_setjd> = m QTS m 
I <ts_$ecurfty_header> ] - for data integrity check the entire TS 
[ <s ignatu re_data> ] - for onfy signing the data contained after the signature segment 
I <slgnature> ] - for authentication of the originator of the entire TS 

<generaLFll_extensions> 
{ <query_request Joop> } 

[ <ts_securityjtral!er> ] - for data integrity check of the entire TS 
<trans_set_trailer> 

- Query request loop to relate optional user data with a query request data segment 

<query__requestJoop> ::= 
<ioop_header> 
<query_request_dala> 
[<user_data>] 

- xioopitraUer> ■ ; - • - - - ~ 

- Query request data segment definition used for Search/List, Retrieve, and Cancel requests 

<query_request_data> QRD <gs> 
<query_requesL_type> <gs> 
<qnJ„id> <gs> 

- Cancel Criteria 

[ <subject_ref_ld>] <gs> 

- Retrieval Criteria 

I <retrievaljmagejcey> ] <gs> 

- Operational data 

[ <color Jncficatoo ] <gs> 

[ <output_type_requested> ] <gs> 

I <secured_resutts_requestJndtcator> ] <gs> 

[ <scale_&ize_reque$ted> ] <gs> 
| <response_media> ] <gs> 
[ <tran3port u .media_requested> ] <gs> 
j <processlng_prioiity> ] <gs> 
| <retaln_custodyJndicator> ] <gs> 
[ <obsoletes_quefy_requestJd> ] <gs> 
[ <maxjapse_time> ] <gs> 
[ <max_matcWng_vtew3_reqd> ] <gs> 
[ <view_side_requested> ] <gs> 
[ <view_snippet_reglon> ] <gs> 

[ <acceptable_compression Jds> ] <gs> 
( <payor_bank_m> ] <gs> 

- Search (and list) criteria 

I <ece J>u$ine$$ w datejrange> ) <g$> 
[ <ece_seq_number_range> ] <g$> 
I <ece_cycle_nuinber_range> J <gs> 
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<application_ack_data> ::= ADS <gs> 

<applicatJon_ack_created_dat8_time> <gs> 
<application_ack^reason_code> <gs> 
<applicatton„ack.diagnostic_code> <gs> 
[ <subject_te_refjd> ] <gs> 
I <subjects Jsd__refjd> ] <gs> 
[ <subject^item_refjd> J <gs> 
t<subjecUtem_viewJd> J <gs> 
[ <subject_qrd_ld> ] <&g> 
[ <numberJtems_matchingLCriteria> ] <gs> 
[ <supplementalJnfo> ] 
[ <image.keys_match!ng.cr1terla> ] <gs> 
[ <restart_point_indicator> ] <tr> 

<appUcation_ack_created.dat0_tIme><1 5fl 5) ::= <x9.dataxusxtime> - time is constrained to HHMMSS 

<app!ication_ack_reason_code><01 /01 ) ::a <accepfed> I 
<results_of_a _llst_request> I <re]ected_referenced_ts> I <faIlure_of_operatlon> 



<accepted> ::s "0" 

<resutts_of_aJi$t_request> ::= "I" 

<rejected_referenced_ts> ::= "2" 

<faUure_of_ operation> ::= "3" 



<application_acK.diagnostic.code>(01/D3) ::= 
<no_enor> I <securityjtailure> I <protoco1_violatiort> 

<bpa_vfolat!on> I <unab!e__toJocate> I <Jmage_fonnat_error> I <out_of.balance> I 
<arrived_toojate> 1 <constraints_exceeded> I <unwfUing_to_perform> I <dc_reserved_ for_X9_use> I 
<user_defined_dlagnostic_codes> 



<no_error> 


::="0° - for reason code = <accepted> only 


<securftyJaJlure> 




<protocoLviolation> 




<bpa_vlolation> 


n 3" 


<unable_toJocate> 


:» "4 a 


<lmage.formaL.error> 


:s n B m 


<out_of_batance> 


:= "6 W 


<arrived_too_late> 


::= "V 


<constraints_exceeded> 


«8" 


<unwiIUng_to_perforni> 


:= u 9° 


<dc_reserved_ for_X9_use> 


:= "10-|.J U 499" 


<user_defined_diagnostic_codes> ::= "500"!. J M 999 U 


<subjecUs_refJd><1G/42) 


::= <ts_ref_id>- to acknowledge at the transaction set level 


<subjectJsd_retJd><18/50) 


<isd_refjd>- to acknowledge at the group of items level 


<subJectJtem_refJd><2Q/58) 


::b <item_refjd>- to acknowledge at the imaged Hem level 


<subjectJtem_vtew_id>{22/66) 


::s <ftem.vlew.id>- to acknowledge at the Hern view level 


<subject_qrd Jd>(1 8/50) 


::= <qrd Jd>- to acknowledge at the query request level 



<number_ttems_matchIng.criteffa>(0iyD6) <numerio 



<image.keys^natchin9.criteria>(34Af) ::= <imagejcey> { <usximago,key> } 
<supplementaUnfo>(01/80) ::= <string> 

- Query or cancel query request functional group definition 
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<lnterpret_bftmap><01/D1) ::= <min_plxeLva!ue_ls_white> I <m!n_plxel_value_is_black> 

<fnInj>lxeLva1ueJs_.whfte> ::= M 0" 
<min_pixel_value Js Jblacto ::= "1° 

<orfcntation>{01/01) ::= <tr_tb> I <r1Jb> I <rlj»t> I <lr_bt> I <tbjr> t <tb_rt> I <bt_rt> I <btjr> 



«dr_tb> ::="1" -DEFAULT 

<rt_tb> ::= "2* 

<rt_bt> ::= n 2 m 

«drjrt> "4" 

<tbjr> ::= "5° 

<tb_rt> ::= °6 B 

<bt_rt> -7" 

<btjr> ::= m B u 



<creation_computer>(01/32) <strlng> 
<view_description>(01/32) ::= <string> 
<&canner_mfgr_name>(01/30) ::= <string> 
<scanner_modeLname>(0l/l5) ::= <string> 
<^ew_capture_softwareJd>{O1/30) ::= <string> 

- Application Acknowledgment functional group 

<applicaUon.ack.fg> ::= 
<fg_header> - where <functionaLgroup_id> value = "72* 

[ <fgjBecurttyJheader> ] - for d ata inte gri ty che ck th e ejgmFG 

^[j^ignatMrejts>_l ~ - jtor_autftenfc^^ 1_1 — — 

- Acknowledgment transaction sets 
{ <applteation_adcts> ) 

[ <tg_security_trailer> ) - for data integrity check of the entire FG 

<fgjtraiter> 

- Transaction set for Application acknowledgment of specific requests 

<appllcation_ack_ts> ::= 

<trens_8eUheadef> - where <trans_seUd> value = "ATS m 

[ <ts_security_header> ] - for data integrity check the entire TS 

I <slgnature_data> ] - for only signing the data contained after the signature segment 

I <slgnature> ] -for authentication of the originator of the entire TS 
<generaLFtLextensfon&> 
{ <application_acK_data> } 

[ <ts_security_trailer> ] -for data Integrity check of the entire TS 
<trans_set_tralter> 

- Details for acknowledging specific requests 
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<x1_<rffset>(01/06) 
<x2_offset><01A>6) 
<y1_offset>(01/06) 
<y2_ottset>(01/06) 



::= <declmaLnumber> 
::= <declmaLnumber> 
::= <decimal_nutnber> 
<declmal_number> 



<snlppet_un*rts_of_measure> 
<clipping_jnfo>(02/45) 



::= <unfts_of_measure> 

[ <cJipping_origin> ] <us> [<clipping_offeet>] 

<clippIng_origin><01/D1) ::= <top_right_comer_QfJmagedJtem> I 

<topjeft_comer_of Jmaged Jtem> I <bottom_right_comer_o1 _lmagedjtem> I 
<bottomJeft_comer_ofJmagedJtern> 

<top.right_comer_cf Jmaged Jtem> -1 ■ 

<topjeft_comer_ofjmaged_item> ::= "2° 

<bottom_right_comer_ofjmaged_ltefn> ::= D 3 U 

<bottofn_lett^comer_ofjmaged_itcm> :s= "4° 

<c«pping_offset>(04/43)::s: [<h1>] <us> [ <h2> ] <us> [ <v1> ] <us> [ <v2> ] 



<hi>(omo) 

<h2>(01/10) 
<v1>(01/10) 
<v2>{01/10) 



:=<numerio - Measured in PiXELs - DEFAULT =1 

:= <numerlo - Measured in PiXELs - DEFAULT e view's maximum horizontal dimension 
:= <numerlo - Measured in PIXELS - DEFAULT* 1 

:= <numerio - Measured in PiXELs - DEFAULT = view's maximum vertical dimension 



<embedded_headerJnfo> 



::= <OTbedded_headerJrtdicator><us><vlew_raster_data_offsct> 



<embedded„header.indicator>(01A>3) :s= <spifl^ | <ansL alim_oda> I <tM.6> I <Joca_fs_11> I 
<reserved_for_x9> I <private_use> 



<spifl> 

<ansi.aHm.oda> 
<tiff_6> 

-<IOCa^fS-11>- 



<reserved_for_x9> 
<pr1vate_use> 



:= -r 



^ m 3 m — 

:= -4" I „ I "499" 
x -500-1^.1-999- 



<view_raster_data.off3et><0im) <numerio 



- View Decoding Information 
<pixds_perJine>(01/08) 
<number_ofjines>(01/08) 
<resolution_unit>(01/01) 



::= <numerio 
::= <numerfo 
::= <none> I <inch> I <centimeter> 



<none> 






<inch> 


... M 2 9> 




<cefitfmetef> 


:= •*3" 




<resolutlon_alongjlne><01/08) 


<numerio 


<resolution_acrossjine>{01/08) 


<numerio 


<tolts_per_plxe!><01 AM ) 


::= <one> 1 <two> 1 <four> I <sbo 1 <eight> 


<ono 


:= -r 


- black and white 


<two> 


:o "2" 


-gray scale 


<four> 


:= "4- 


-grayscale 


<six> 


::= -6" 


-grayscale 


<eight> 


*g" 


-grayscale 
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<interpretj>ftmap> <gs> 

[ <orientation> ] <gs> - default { Irjb ) 

- Partial View Information 

I <snippetJnfo> ] <gs> - default not present 

[ <c!lppingJnfo> ] <gs> - value shall be not present when image is not clipped 

- Other Information 

I <embedded_rteaderJnfo> ] <gs> 
[ <creatton_computer> ] <gs> 
[ <view_description> ] <gs> 
[ <scan ner_mfg r_name> ] <gs> 
[ <scanner.modeLname> ] <gs> 

[ <view_captiire_software> ] <tr> - default { none-present ) 

- FilP view detail segment data elements 

<rtem_vl0wjd> (22/66) ::= <ftem_ief_W> M . w <locaI - valiie> 

<view_creation_date><oa/Q8) ::= <X9_date> 

<view_raster_data_ske> (01/10) ::=<numerlo 

<view_sidejndlcaior>(01/01) ::= <frontah> I <rear> 

<frontal> ::="0" - DEFAULT 

<rear> ::="1" 
<snippetjnf o>(01 /31 ) ::= [<snippe|_name> ] <us> 

[<snlppet_origfn> <us> 
<snippet_offset> <us> 

[<snlppet_unhs_of_measure>]] - ABSENCE assumed to be INCH unless stated otherwise 

<snippet_name>{01/02) ::= <courtesy_amourrt> I <payee_name> I <payor_name> I <mlcr_codeJine> I 
<sig nature>l<o^ <bofd^endorsetnem> 1 

<sub3equentJ>anleendorsement> I <subsequent^ban*ename> I <re8erved.for.x9.snippel.tise> I 
<reserved_for _private_snippet_use> I <name_not_provlded> 



<name_not_prov<ded> ::= "0" 

<courte8y_amount> ::= "1 " 

<payee_name> ::= "2° 

<payor_name> ::= "3" 

<micr_code_line> ::= "4" 

<s!gnature> ::= "5" 

<date M fromJtem> ::= "6" 
<legal_anM>imt> "7" 
<payee_endorsement> 
<bofd_endorsemartt> 
<subsequent_bank_endorsement> 
<stib&equent__banlt_name> 



:= "9" 

"10" 
= "11" 



<reser^_1or_x9_snippeOi&e> ::= "12" I ~ I "49" 

<reserved.forj>rivate.snippet_.use> ::= "50 1 I "99" 

<snlppet_orlgirt>(01/01) ::o <top_right_corner_of_snippet> I <top Jefl_comer_of_snippet> I 
<bottom^ght_comer_of _sni ppet> I <t>ottomjeft_comer_of_6nlppet> 

<top_right_comer_o1_snippet> "1 " 
<top_lefLcomer_of_snippet> ::= "2" 
<botto«n_right_corner_of_6nippel>::= "3" 
<bottom Jeft.coiner„Ql_snIppet>::o "4" 

<snippet_offset>(07/27) ::= <x1.otfset> <usxx2_offset> <us> <y1_offset> <us> <y2_offset> 
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<eompressionJndicators> <gs> 

<view_count> <gs> 

[ <fih_cross_references> ] <gs> 

[ <item_amount> ] <gs> 

[ <payor_banK_routing_number> ] <gs> 

[ <rfmage Jcey> ] <gs> 

[<user_data_presentJndicator>] <tr> 

<item_refjd> (20/58) «dsd_reUd> tt " <tocal_yalue> 

<compression Jndicators> ::= <view_compresslon_algortthm Jd> 

{ <us> <view__compressk>n_algorithmJd> } 

<ftem_views Jength>(01fl 0) ::= <numerio 

<view_count>(01/08) <numerio 

<iih_cross_references>(1 6/257) ::= <ts_cross_reference> 

<hem_amount>(02/1 2) ::= <numerio 

<payor.banlerouttng_.number>(09A>9) ::= <routing_number> 

<imagejcey> (34/34) ::= <stnng> I 

<ecc_routing_number><ece_busine&s_date^ 

<ece_routlng_number> ::= <routing _number> 

<ece_business_date> ::= <x9_date> 

<ece_ecquence_number> ::= <string> 

<ece_cycle_number> ::= <string> 

<user_dataj)resent_tndicator>(01A)1) ::: <absent> I <present> 

<absent> :^ m C m - DEFAULT 



_<present> .: , :;g-^1 " 



- Information for each view definition 
<ftem_views> 

<ioopJieader> - value for <loop_id> = m 3 m 

<ftem_vetw_data> 

<view_binary_data> 

<k>opjbraner> - value for <loopjd> = m 3 m 

- Compressed (or uncompressed) binary raster data for a single (partial or full) view. 
<view_binary_data> ::s <bift_segment> 

- FIIP view's raster details definition, Le. 9 for a single view of a single side 

<ftem_ytew_data> :u= IVS <gs> 

- View processing information 
<ftem_vtewjd> <gs> 
<vtew_creation_date> <gs> 
<view_compression_aJgoJd> <gs> 
<view__raster_data_sfee> <gs> 

[ <view_&ideJnd]cator>] <g6> - default {frontal} 

- View decoding additional information 
<pixels_perjine> <gs> 
<number_of_Unes> <gs> 

[ <resolution_unit> ] <gs> 
<resolution.aJong.line> <gs> 
<resolution_across Jines> <gs> 
<bfts_per_pixet> <gs> 
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<ftem_group_ts> ::= 
<tran8_8et_header> - value for <trans_seLfd> = 'ITS' 

- General transaction set information 
<general_Flkextensions> 

- TTEMJSUBGROUP loop contains views for items that have been grouped into bundles. 
. . { <item_subgroup> } 

- X9 transaction set trailer 
<trans_set_trailer> 

- Item subgroup (loop) structure definition 

<ftem_subgroup> ::= 
<loop_header> - value for <toopJd> = m 1 " 

<ttem_subgroupjnfonnation> 
{ 4tem_data_loop> } 
<loop_trailer> 

- FIIP item Subgroup Information segment definition 

<item_subgroupjnformation> ISD <gs> 
<ftem_dataJoop_length> <gs> 
<isd_ref Jd> <gs> 
<lsd.itefn„oountxgs> 
<isd_subgroup_recipientxgs> 
[ <dsd_cross_refere nces> ] <gs> 
[ <isd_8ubgroup_amount> ] <tr> 

<ftem_data_loop Jength>(02/1 0) ::= <numerio 

<isdjet_id><1g/50) <ts-ret Jd> y "<locaLvalue> 



<locaLvalue>{01/07) ::= <numerto 

<isd Jtem_count>(01 708) <numer1o 
<isd_cross_ re fere n ces>(16/257) <ts_cross_references> 
<is4_8ubgroup_arnount><01fl6) ::= <numerio 

<Jsd_subgroup_reclpient>{Q4/18) <flLfd.quaUfier> <us> <isd_6ubgroup_redpIentJd> 

- -identifies to whom an image item is to be addressed 



«dsd_subgroup_recipienUd> (01/1 5) ::= <string> 

- Item data definition 

<ftem_data_toop> ::= 
<loop_header> - value for <hopJd> «= *2 m 

otem_Jnfonvtiit2on> 
[<slgnature_data>] 
[<stgnature>] 
[ <user_data> ] 
{ ^tem_vlews> } 

<ioop_traiter> - value for <doopJd> = *2 m 

- FIIP Item information segment definition 

<ttemJnfonnation> IIH <gs> 

<item_vtewsjength> <gs> 
l<Hem_ref Jd>) <gs> 
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<standard_version> <6tandardsJdentifierxgsxv6mtonJd> 
<standards .Identifier (01/01) ::= <id> - data element 110 : X12.S 
<versionJd> (05/D5) ::= <ld> - vafc/e is 00305, data element I1 1 : X12.S 

<inter_control> (09/09) ::= <numeric>- data element 112 : X12.S 

<ack_requested> (01/01) ::= <id>- data element 113 : X12.5 

<testJndicator> (01/01) ::= <id>- data e/emem W ; X12.5 

<subelement_Gcparator> (01/01) ::= <strlng>- rtate element 11$ : X12.5 
<number_groups> (01/05) <numeric>~ date etemen/ /I6 ; Xf£5 

- Financial Data functional group stmcture definition 

<flnanclal_data_fg> ::s 
<fa_hcadcr> - value for <functiona Lgroup_ld> = *70 m 

I <fg_Becurity.header> J -for data integrity check the entire FG 
[<signature_ts>]- for authentication of the originator of the entire FG 
- NOTE - Security is not explicitly provided below this point intheFG structure 
{ <financiaLdata_t_set> } 

I <fg_security_trailer> ] - for data integrity check of the entire FG 
<fg_trafler> 

- Financial Data transaction set structure definition 

<financiaL<tetaJ_set> ::= 
<tran8_set_header> - value for <trans_$eUd> = "FTS" 

<general_m H extensioRs> 

- Finan cial da ta often enco ded perX9.37 

<financ ial data> 



- X12 trailer for transaction sets 
<trans_set_trailer> 

- Financial data segment definition 
<financiaLdata> <bin_segment> 

- Item Views functional group structure definition 
<hem_views_fg> ::= 

<fg_header> - value for <tunctionaLgroupJd> = V1 * 

I <f&_securtty_header> ] - for data integrity check the entire FG 
[ signature Js>] - for authentication of the originator of the entire FG 

- NOTE - Security is not explicitly provided below this point intheFG structure 

- FIIP group of related views transaction sets 
{ <ftem_group_ts> } 

I <fg_security_traller> ] - for signing or integrity check the entire functional group 

- Functional Group Trailer 
<fg_traitef> 

- Item Group transaction set structure definition 
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<ab!o 

«reserved_for_X9> 
<private> 

- End common elements 



:= "5" 

:= "6" I I M 499 M 
x w 500" I ..I "999" 



- The Fll protocol's interchange structure 

<fii_structure> ::= 
<inter_header> 
{ <financiaL.data_fg> } 
{ <item_views_fg> } 
{ <functional_ade.tg> } 

{ <application_aekJ9> } 
{ <query_requests„fg> ) 
<dnter_trailer> 

- At least one functional group is always present even though m * 

- Interchange basic structure Identifies each as optional 

- Interchange Header and Trailer imported from X12.5:1991, included for reference only 

<dnter_header> ::= ISA <gs> 
<authorization> <gs> 
<security><gs> 
<sender> <gs> 
<recetaer> <gs> 

<inter_date_tlme> <gs> 

— <standard-version><gs> 

<Inter_control> <gs> 
<acK_requested> <gs> 
<tesUndicator> <gs> 
<subelement M 8eparatorxKr> 

<dnter_traltor> its IEA <gfixnumber_groupsxgsxintcr_controlxtr> 

- ISA and IEA component data definitions 

<authorization> ::= <authortzation_quaJrfief> <gs> <authorixattonJnto> 

<authorizatton_qualifter> (02/02) ~ <id>- data element 101 : X12.5 
authorization Jnfo> (10/10) ::= <string>- data element 102 : X1ZS 

<security> ::= <securfty_qualrfler> <gs> <&ecurftyjnfo> 

<security_quallfler> (02/02) ::s <id> - data element 103 : XI ZS 
<securttyJnfo> (10/10) ::= <string>- data element 104 : X12.5 

<sender> ::= <interJd_quaBfier> <gs> <sender_W> 

<inter Jd_qualrfler> (02/02) ::= <ld> ~ data element 105 : X1ZS 

<senderjd> (15/15) ::= <string>- data element 106 : X12.S 
<reoetver> <JnterJd_qualHier> <gs> <reccrverjd> 

<receiver Jd> (15/15) ::= <string>~ data element 107 : X12.5 

dnter_date_tJme> ::= <inter_date> <gs> <inter_time> 

<inter M date>(0S/D6) ::= <date>- data element 108 : X12.5 

<inter_time>(04/D4) ::= <hourxminute>- data element 109 : X12.5 
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<typ^of^request>{01/D2) <func.acUs.requested> I <app_ack J3_requested> I 

<both_fa_and_aa_are_requested> 

<func_ackJ$_requested> ::= *tr 
<app_ackjs_requested> ::= "1 w - DEFAULT 
<both_fa_and_aa_are_req uested> ::= T* 



<acK_sccurity> ::= <no_secJs_requested> I I <non_repudiation_secJs requested> I <macd 
_secjs_requested> I <data_protected .see Js_requested> I 

<non^repud^and_data^rotccted^sec^te^ucsted> I <non_repud_and _macd-sec_ls_requested I 
<tnacd.and_dataj>retected.8ec i8.requested> I <maod_dataj?rotectcd_and non_repud_secJs_rei 

<no_secJs_requested »= M o" 

<non H repudiation H 8ecj8 H xequested>:u= "1 " 
<nwwd_8ecjs_requested> "2" 
<data w protected_sec_ls.requested>:^ "3" 
<non_rcpud_and_datajirotected_secjs_requested>:^= T 
<non_repud_and _macd_secjs_requested>::= u s* 
<macd_and_data_protected_sec_ls_requested>::r: M 6" 
<macd_data_protected_and non_repud_secJs_req>::= U V 



<send_acknowtedgments^to>(04^8)::= <fiijd_qua!ifier> <us> <fii_ac^rectpiefiUd> 

- identifies to whom a Fll acknowledgments is to be addressed if other than the originator 
<ffljd_qualffier> (02/02) ::= <interjd qualifier 
<fiLaclerecipienUd> (01 A 5) ::=<string> 

<ts.cross,refererexs><i6tt57 ) ~ <te_ieUd> i <us> <ta ref kt> } - may b» mp*^ up to six times 



I <resenred_for_x9_use> I <private.fonnats> 

<**-37> ::= • _ DEFAULT 

<eccho> :: - -2" 

<federaLreserve_dps_fonnat> "3* 
<reservedJor_x9ju$e> ::= m 4* I _ I "so" 

<q>rivate.fonnat8> ::s "51" I ... I D gg" 

<^m^of^finandaLdata^items>(01/D8) : - <numerfc> 

<counuof_lmagedjrtems>(01/08) ::= <numerio 
<item_group.amount>(01/16) <numerio 
<ftem^roup.recipfenUd>{04A8)::= <send.acknowledgmefits.to> 
<item_subgroup_c©unt> (01/08) <numerio 

- Compression Algorithm Choices 
<vfew.compresslon.algojd>(01/03)::= <flip_registered_algos> 

<f»P^lstefed_algos> <wicompressed> I <t$_fec8hnfle_com P fB88ion> « <jpeo baseline> I <j Wg> 

I <aWo I «reserved.for_X9> l<private> ^ ^ 

- X9.46 Registered Compression algorithm identifiers 

<uncompressed> »e "i" 

<t6JacsimUe_compression> ::= "2" 

<jpeg_baseline> ::s "3" 

<jWg> ;;= -4- 
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<generaLFIt_extensions> ::= GFD <gs> 
<tsjength> <gs> 
<ts_refjd> <gs> 
[ <type_of_ts_data> ] <gs> 
[ <fecipient„aeK.request> ] <gs> 
[ <send_acknowtedgments_to> ] <gs> 
[ <ts_C!t>ss_references> ] <gs> 

- Following used in <flnanciaS_dataJs> only 
[ <type_of_financiaLdata> ] <gs> 

[ <count_of_financlal_data Jtems> ] <gs> 

- Following used in <item_grcup_ts> only 
I <count_ofJmagedJtems> ] <gs> 

[ <item _group_amount> ] <gs> 
[ <ttem_group_recipterrtJd> ] <gs> 
[ <ftem_subgroup_count> ] <tr> 

<tsjength><02fl5) ::=<numcrio 

<ts_refJd>(16/42) ::= - provided for Cross-referencing purposes 

<fg_date> M ." 
<app__sender_Id>V 
<function_control_number> u - H 
<trans_set_conti©Lnumber> 

<type_of_ts_data><01/03) ::= <response_to_quecy> I 

<forward_processlng> I <retums>l <posHtve_pay> l<account_recon>J <subpoena> ksignatuie_verffy> I 
<statementing> I <mlxed_type> I <reserved_forjc9> I <private_ts_type> 

<re8portse_to_query> "1 ■ 

_ <torward_proces3lng> ::= "2" 

I <retums> " :;=-3- — 1 — — ...... . 

<pos*tive_pay> ::="4 B 

<iccount__r€con> ssasV 

<subpoena> 

<slgnaturD_vertfy> ::=T 
<statefncnling> ::= a 8** 
<mlxed_type> ::= "9" 

<reserved_tor_x9> :u= "1(H ~ i B 500 w 

<private_ts_type> ::= "501 "I 1-999" 

<recipient .ack.request><01/04) [<ack_condWon> ] <us>[<type_oOequest>] <us> [<ack_securfty>] 

<ack_condltion>(01/01) ::= <ack_not_requested> I <acK.ooJallure_or_success> 

1 <ack_only_onJaiture> I <ackjonly_on_6uc©ess> 

<adenot_requested> "IT- - Overides any value if present in <fypejof_request> 

<ack_on_fallure_or_succeas> ::= "I" 
<ack_only_.on_failurc> ::= "2 tt - DEFAULT 

<ack_onty_on_success> ::= "3" 
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<no_ofJncluded_sets> (01/06) ::= <numerio 
<no_<rf_received_sets> (01/06) ::= <numerio 
<no_aLaccepted_sets> (01/06) ::= <numerio 
<fg_syntajc_er_cd> (01/03) :;= <Jd > 

- END of IMPORTED FG, TS and Segment structures from X12 
~ BEGIN definitive 

- SIGNATURE Transaction Set component data elements for signing 

- the entire contents of a functional group 
<signalure_ts> :: - 

<trans_set_header> - the value of <trans_seLid> component is 'STS m 
<signature_data> 

<slgnature> - BtNsegment syntax 
<trarts_set_tiaiter> 

<signature_data> ::= SIG <gs> 

<securtty_orig_name> <gs> 
<securfty_reclp_name> <gs> 
<authent_algorrthm JW> <gs> 
<Key_and_or_Mock_sfce> <gs> 
[ <tengtti_of_data> J <tr> 



<authem.algorittunJd> (01/15) ::=<rsajso0796> I <dsa> I <ldentifier.6ti1r>g>{<identmer^8tring>) 

<rsaJso9796> <rsa_wWumd5 1 <isa_with_sha-1> I <rsa with mdc2> 

--from1$Q/lEC9796~~ " 



<rsa_wtth_md5> : 
<rsa_with_8tia-1> : 
<rsa_with_mdG2> : 


:= "43.14.3^23° 
:= U 43.14^2J29 M 
:= "43.14^2.14" 


<dsa>::= <dsa_with-sha~1> 
<dsa_wittvsha-1> 


= "43.14.3A27" 


<key_and_orJWocK_size>(01/06) <numerio 


- END SIGNATURE Transaction Set 


-SIGNATURE segment 




<signature> 


::= <Wn_segrnent> 


- END Signature Segment 




- User Data segment 




<user_data> 


::s <i>in_segment> 



- END User Data Segment 



- FIIP General Functional Group Header Extensions Transaction Set 
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<data_segment_note> ::= AK3 <gs> 

<segment_id_code> <gs> 
<seg_positionJn_trans_set> <gs> 

[ <toop Jd.codo ] -the value of the loop id of the subject loop being acknowledged { 

<g9xsegment_syntx_er_cd> } <lr> - max 5 instances of error codes 

<loopjd_code> ::= <loopjd> 

<segmentjd_codo{02/03) ::= 
<tg_security_header_segment> I <fg_securtty_traller_segment> I <ts_securlty_headcr_segmem> I 
<ts_security_trailer_segment> I <signature_data_segment> I <generaLFII_extensions_seginent> I 
<item_subgroupjevet> I <Hem.subgroupJnformatlon„Geg> I <ftem_datajevek> I 
<dtemJnformation^6egment> I <ftem_vtowjevel> I <ttem_view_data_segment> I <binary_data> I 
<apptication_ack^data_segment> I <quefy_request_data_segment> I <string> 



<fg_securityjieader_segment>::= *S1S" 

<fg_securfty_trailer_$egment> "SIE* 

<ts_security_heacter_segrnent> : := "S2S" 

<ts_security_trailer_segment> ::= tt S2E B 

<sigrurtiire_data_segment> ::= "SIG" 

<general_RLextenslons_6egment> ::= "GFD° 

<item_subgroup Jevel> ::= "LS1 n 

<ftem_subgroupJnforrnatk>n_seg> ::= "ISO 0 

<rft£m_data_level> ::= "LS2" 

<ftemJnformation_8egmcnt> ::= "IIH° 

<item_vlew_level> ::= "LS3 a 

<item_vlew_data_6egrnent> ::= "IVS" 

<binary_data> :s="BIN" 

<applicatlon^ack_data_segment> s-^ADS"- - 

~ <queryirequestidataisegment> ::= "QRD" : 

<seg_position_ln_trans_set> (01/06) ::= <numerio 

<segment_syntx_er_cd> (01/D3) <id> 

<data_etement_note> ::= AK4 <gs> 

<eLposftionJn_segment> <gs> 
[ <data_etement_ref_no> ] <gs> 
<element_syntx_er_cd> <gs> 
[ <value_of_bad_element> ] <tr> 

<eJ_positionJn_segment> (01A)2)::= <numerio 

<data_eteroent_ref_no> (01/04) ;:= <numerto 

<etement_syntx_ec_cd > (01 AO) ::= <id> 

<value_of_bad_eternent> (01/99) <string> 

<trans_seOespon8e_trailef> ::= AKS <gs> 
<trans_set_ade_code> { <gs> <trans.sel_syntax.efTor.code>} <tr>- max 5 instances of additional note 
codes 

<trans_se|_ack_code> (01/01) ::= <id > 

<trans_selL.note_codetrans_6et_syntax_error_code> > (01/03): u= dd > 

<fg_response_traHer> ::= AK9 <gs> 
<fimctional_group_ack_code> <gs> 
<no_ofJnduded_sets> <gs> 
<no_of_received_sets> <gs> 

<no_of_accepted_sets> { <gs> <fg_$yntax_er_cd> } <tr> -max 5 instances of additional error codes 
<tunctional_group_acK_code> (01/01) ::=<Jd > 
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<iength_of_data> (01/1 8) ::= <numer!o 

<JnitiaJization_vectoi> (1 6/16) <string> 

- FG Security trailer 

<fg_security_traUer> ::= SI E <gs> <message_auth_code> <tr> 

<message_auth_code> (09/09) ::= <string> 

- END Security functional group 

- X12.58 SECURITY transaction set component data elements 
<ts_security> ::= S2S <gs> <securfty.SxS> <tr> 
<ts_security_trailer> ::= S2E <gs> <message_auth_code> <tr> 

- END Security transaction set 

- X12.58 SECURITY data elements 

- End Security data elements 

- X12 997- functional acknowledgment 

<functional_ackJg> ::= 

<fg_header> - the value of the component <functionai_group, 
<funetiona1_transactioru&et> 

— <f£Utraiter> .. - 

<functional_transaction_set> 
<trans_set_header> - the value of the component <tran$_set_hl> is a 997 m 

<fg_response_header> 

{ <trans_80t_responseJoop> } - max 999,999 loop iterations 
<fg_re$ponse_trailer> 
<trans_se|_trailer> 

<trans_set_responseJoop> ::= 
<trans_set_response_header> 

{ <data_segment.response_loop> }- max 999,999 loop iterations 
<trans_setjpespon&e_traflef> 

<data_segment_re$ponseJoop> ::= 
<data_segment_note> 

{ <data_e1ement_note> } - max 99 instances 

- X12 997- segments 

<fg_response_header> ::= AK1 <gs> 

<functionaJ_group_id> <gs> - the value of the FG identifier of the subject FG being acknowledged 
<funct*on_contro!_number> <tr> 

<irar\6_set_rcsponse_header> ::= AK2 <g$> 
<trans_set_ld> <gs> - the value of the TS identifier of the subject T$ being acknowledged 

<trans_set_cofitroLnumber> <tr> 



Jd>is'FA m 
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<loopJd>{01/D4) ::= <string> I - Only X9.46 registered values 

<ftem_subgroup_or_query_req> I «dtem_data> I <itcm_view> 

- X9.46 registered <toopjd> values 



<ftem_6ubgroup - or_query - req >::= "1" 
<ftem_data> ::= "2° 

<hem_vlew> "3" 

- X12.22 loop trailer definition 

<loopjraiter> ::= LE <gs> <loop Jd> <tr>~ me value is the loop-Id value used in the 

corresponding LS segment 

- X12.58 SECURITY functional group component data elements 

<fg_security> ::= S1 8 <gs> 

<securtty_SxS> <tr> 

<securfty_SxS> ::= 
<security_type> <gs> 
<security_orig_name> <gs> 
<securfty_recip_name> <gs> 
[ <authentjcey_name> ] <gs> 
[ <authent_serv_code> ] <gs> 
[ <encryptionJcey.name> ] <gs> 
[ <fincryptiofueerv_code> ] <gs> 
( <tength_oO!ata> ] <gs> 
[ <initlafization_vector> ] 

• " n , ' <securtty_type>~ (02/02) ::s <id> t 



<authentJcation_oniy> I <authentication_and_data^itrtectfon> 1 <data_protection_onty> 

<authentication_only> ::= "AA° 

<authentication_and_datajrotection> ::= "BB" 
I <data._protection_.onfy> ::= "EE" 

<security_orig_name> (04/16) <string> 

<security_recfp_name> (04/16) ::= <string> 
<authent_lcey_name> (01/16) <string> 

<authem.serv_code> (01/01) ::= <id> I <x9_9J>lna?y_da1a> I <x9jl7_stdLvaIue> 

<x9_9_binary_data> ::»"1" 
<x9_1 7_std_value> ::= m 2 m 

<enciyption_key_name> (01/16) ::= <6tring> 

<encryption_serv_code> (01/03) ::= <id> I <cbc_no_fiiter> I <cbc_hex_fitter> I <cbc_ascii_fitter> I 
<*bc_asd!J>audotJirter> I <cbc_miitually_definedjitter> 1 <cfb_A.noJilter> I <cfl>_8_hexjirter> I 
<efb_8_asciLfitter> I <cfb.8.asclLbauctoLfiltei> 



<cbe_no_filter> 

<cbc_hex_filter> 

<cbc_asci i_filtor> 

<cbc_asdLbaudot_filter> 

<ct>c_mutuany_deflnedjRtter> 

<cfl>_8_no_filter> 

<cfb_8_hex_fitter> 

<cfb.8_asclLfi*tef> 

<cfb.8_asdLbaudot.fiKer> 



:=-20- 
-s:"21- 
--22' 
:= "23° 
:=°2T 
:= w 40* 
oMI' 
-="42" 
:=°43" 
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<financlal_data_group> ::= "70" 
<ftem_views_<jroup> •71° 

<app!ication_ack_group> ::=*72° 

^ <query_requests_group> ::= "73" 

<functionaLack_group> ::= a FA° ~ Imported from X12 - 997 functional acknowledgment 

<private_types> ::= "80" I ~ I "99" 

<app.reoefverJd> (02/15) ::= <string> 

<app_sender Jd> (02/1 5) ::= <string> 

<fg_date> (06706) ::= <date> 

<fO_tjme> (04/08) ::= <time> - The originator's LOCAL time, not GMT 

<funcHon_contro|_number> (01/09) <numerio 

<standard> (01/02) ::= <string>- the value *X9* is used 

<version> (01/12) ::= <string>- bytes 1-6: use the value '003050' 

- bytes 7-12: use the values "001001 m 

- X12.6 functional group trailer definition 

<fg_trailer> ::= GE <gs> 

<no_lneluded_sets> <gs> 

<function.controLniimber> <tr> - the value corresponds to value in its peer in the <fg_header> 

<noJncfaided_sets> (01/06) <numerio 

- X12.6 transaction set header definition 

<trans_set_header> — ::=ST<gs> — 

~<trans;;setjd>~<gsx 



<trans_sm_control_number> <tr> 

<trans_set_M> (03/03) ::= <string> I - 0nfyX9.46 registered values are used 

<financiaLdata_set> I <Jtetn_£roup_set> I <appUcation_acK_set> I <query_requests_$et> I 
<signatures_set> I <functional_acfc_set> ~ 

- X9.46 <trans_set_fd> registered <string> values 

<fmanclaLdata_set> 
<ftem_group_set> 
<appncation.acK.8et> 
<query_reque8ts_8et> 
<signatures_set> 
<functional.ack.&et> 



::= "FTS° 

:^-rrs n 

::= •ATS" 
"QTS" 

::="997" - Imported from X12 - 997 functional acknowledgment 
<±rans_s<rt_comrol_number><04/09) :;s <string> 



- X12.6 transaction set trailer definition 

<trans_8elL_trailer> :u= SE <gs> 

<number_of Jncluded_segments> <gs> 

<trans.seLcontroLmimber> <tr>- the value corresponds to value in its peer in the <trans_seLheader> 
<number_ofJnclu<fed_8egments> (01/10)::= <nutnerio 

- X12.22 loop header definition 

<loop_header> ::= LS <gs> <toop_ld> <tr> 
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<20th> ::= "19° 

<21st> ::=:"20- 

- Components of <time> data element 109 : X12.5 

<tlme> ::= <hourxminute> [<seconds>] 

<hour> ::= "00" I "00° I ... I "23° 

<miniite> ::= "00" I "00" I ... I "59" 

<seconds> ::=<Jnteger_seconds> [<decimal_seconds> ] 

<integer_seconds> ::= "01 • I "02" I ... I "59" 

<decimal_seconds> ::= <digit> { <digit> } 

- FIIP Routing Number Syntax 
<routing _number>{09fl)9) ::= <numerio 



- BEGIN IMPORTS FG, TS and Segment structures from X1 2 standards 
- All are included for reference only - NOT DEFINITIVE. 

~ X1222 Bin Segment 

<bin_segment> ::» BIN <gs> 
<Sength_of_blnary_data> <gs> 
<binary_dataxtr> 

<length_of_blnary_data> (01/15) ::= <unsigned_integer> 
<b»nary_data> (01/(10 15 - 1)) :£= <*inary> 

~^X12:6~standard's version fldmtifier syntax 

<standard_yerston_id> (01/12) 
<version> - The value for <verston> is 003 

<release> - The value for <release> is 050 

<x9_verslon> - The value for <x9_version> is 001 

<x9_retease> - The value for <x9_retease> is 001 

<vers!on> (03/03) ::= <numerio 

<refease>(03/D3) ::= <numerio 

<x9_verslon> (03/03) ::= <numeno 

<x9_release>(03/03) ::= <numerio 



- X12.6 Functional Group Header Definition 

<fg_header> ::s GS <gs> 

<functional_group_ld> <gs> 
<app_sender Jd> <gs> 
<app_recefverjd> <gs> 
<fg_date><gs> 
<fg_time> <gs> 

<function.controLnumber> <gs> 

<slandard><gs> 

<verston> <tr> 

<funct)ona1_groupJd>(02A>2) ::= <string> 1 - X9.46 registered values onty 
<financiaLdata_group> I <ftem_vtews_group> I <application_ack_group>l 
<query_requests_group> I <functionaJ_aclegroup> I <private_types> 

-X9.46 <functionaL_group_id> registered values only 
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-IMPORTS 

<ack_requested>, <lnter_date_time>, <lnter_header>, <inter_traHer>, <inter_control>, 
<receivef>, <standard_version>, <secunty>, <sender>, <test Jndicatoo 
FROM ApplicationControlStructure { X1 2.5:1 991} 

<toinary>,<date>, <digtt>, <xfectmaLnumber>, <lower_caseJetter>, <numerio f <space>, <spedal_char>, 
<string>, <time>, <uppercasejetter>, <unsignedjnteger>, <ottier_speciaLchar>, <national char> 
FROM ApplicationControlStructure { X1 2.6:1 991 }; 

BIN, GE, GS, LE, LS, SE, ST # SI E t S1S, S2E, S2S 
FROM SegmentDlrectory { X12.22:1991 }; 

SxS 

FROM SecurrtySegmentSpecifi cation { X1 2.58:1 991 }; 

- BEGIN the Protocol 

- Common encodings and grammar 

<strin 9 > "= <non_space_char> I <space>{<non_space.char> I <space>} 

<charactel > <uppercase_letter> I <digit> I <speclal_char> I <space> I 

<lower_caseJetter> I <other_8peciaLchar> I <nationa!_char> 

<non.6pace.ehar> ::= <uppercasejetter> I <digft> I <space> I <lower case letter> I 

<other_$pedal_char> I <natfonal_char> 

::= <string> - data element 115 : X12.S 

:z= [+ 1 - ] <unsfgited_decimaLnumber> 

::= <unsigiiedjmeger> I \" <unsignedjnteger> I 



<us>(01/01) 

<decimaLnurnber> 

<unsigned_decimaLnumber> 



<unslgned_lnteger> ". M _{<d)glt>> 
:=[+!-] <un$lgned_integer> 

<diglt>{<dlgrt>} 
:=<detter_or_digit> { <letter_or_dIgit> } { <space> } 
:= <uppercasejetter> I <digit> 
;:s <unsignedjnteger> { V <unsignedjntegef> } 

{ <select_alpha_numerics> } 

::= <numerio ( <hex_alpha> 

:= "A" I .„ I "P 

::= <inch> I <centimeter> 

ts"2" -DEFAULT 
;= m Z" 



<numerio 

<unsignedjnteger> 

<id> 

<ietter_or_digft> 

<identtfier.string> 

<hex_string_char> 

<BetectjaIpha_numerics> 

<fiex_alpha> 

<unfts_of_measure> 

<incft> 
<centimeter> 



- Components of <date> data element 108 : X12.5 

<date> <yearxmontfixday> 

<year> ::= <dlglt> <rilgrt> 

<month> "01" I "02" I ... I "12 a 

<day> :is "01* I "02" I ... I "31" 

- Components of <x9_date> element 

<x9_date> ::= <centuryxdate> 

<century> ::= <20thx21 st> 
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Annex A 

(normative) 

FIIS Interchange structure 

This annex is provided to clarify the interchange data structures exchanged in accordance with this 
financial image interchange standard. The structures are restated using BNF in accordance with the 
conventions and concepts set forth in X12.5:1991 and X1 2.6: 1991. 

The BNF notation, contained in this annex, may be reproduced freely. All other aspects are covered by 
ANSI copyright infringement protection associated with this standard's publication. 

This annex is divide into several areas (or groupings) which appear in the following order 

1. Common Encodings and grammar 

1.1 Primitive encodings and grammar; 

1.2 X1222 Imported common encodings; 

• Bin Segment and standard version syntax; 

• General Functional Group (FG) Header and Trailer; 

• General Transaction Set p~S) Header and Trailer; 
• - Loop-Header and Trailer. 

• Security FG and TS Header and Trailer. 

1.3 Signature TS and Segment; 

1.4 General Fll Extensions foraTS 

2. FIIP Interchange Structure 

2.1 X12.5 Imported Interchange Header and Trailer 

3. Financial Data syntax for FG, TS and Segments 

4. Items (views) syntax for FG, TS and Segments 

5. Acknowledgments syntax for FG, TS and Segments 

6. Query Requests syntax for FG, TS and Segments 

NOTE - The clause numbers used above indicate the sequence of their appearance. 

fiis_interchange_syntax { X9.46 : 1995 } 

BEGIN - FIIS interchange syntax 
EXPORTS; -everything 
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Additionally, an implementation of the Fll shall declare the transfer means provided with its 
implementation, and whether supported optional elements of protocol are accessible by the Fll-system- 
user through the Fll-translator, and if the receiving Fll-translator presents these elements of protocol to 
the Fll-system-user. 
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etc. A conformant implementation shall be able to demonstrate adherence to these requirements 
specified in these categories. 

7.3.1 Static requirements 

A Fll-translator shall be said to support upon receipt a particular element of protocol if, and only if. it 
accepts, preserves, and emits, in full accord with this Standard, that particular element of protocol to the 
Fll-system-user whenever it is called upon by another Fll-translator. 

A Fll-translator shall be said to support upon origination a particular element of protocol if, and only if, it 
accepts, preserves, and emits, in full accord with this Standard, that particular element of protocol to 
another Fll-translator whenever it is called upon by its Fll-system-user. 

A Fll-translator shall satisfy the following static requirements: 

• A daim of conformance shall state which conformance class its supports on origination and 
reception (see 72.). Base conformance class is Class I; 

• A conformant Fll-translator shall Implement for origination, all mandatory components of the EDI 
ISA/IEA Segments.. A conformant Fll-translator shall implement, for origination, the Fll functional 
groups, Fll transaction sets, and Fll data segments as defined in clause 6 per the class to which 
conformance is claimed. A conformant Fll-translator shall Implement, for origination, all mandatory 
components within the Fll functional groups, Fll transactions sets, and Fll data segments for which 
conformance is claimed. Further, a conformant Fll-translator may implement, for origination, optional 
components within the Fll functional groups, Fll transaction sets, and Fll data segments for which 
conformance is claimed. 

• For reception, a conformant Fll-translator shall implement all mandatory components of the EDI 

- ISMEArand shall handle and ms^e a^ 

to the Fll-system-user. Further, a conformant Fll-translator shall implement for reception the Fll 
functional groups, the Fll transaction sets, and the Fll data segmen ts as defined in clause 6 as per 
the class to which conformance is claimed. A conformant Fll-translator shall implement for reception 
all mandatory components of the EDI ISA/IEA, and shall handle and make available (see 6.1 2) all 
optional and conditional components to the Fll-system-user. 

• Class III and IV conformant Fit-translators shall identify the specific security mechanisms and 
algorithms to which support is claimed; 

• Each Fll shall support the requirements of 622 through 6.4.4.3.28, inclusive; 

• All conformant translators are expected to be tolerant of received protocol elements, even if 
support on origination or reception is not claimed. 

7J&2 Dynamic requirements 

A Fll-translator shall satisfy the dynamic requirements specified in clause 6: 

• Fll-translators claiming to be Class II or IV shall be able to demonstrate both successful and 
unsuccessful responses to query requests; 

• A conformant Fll-translator shall demonstrate the ability to generate the appropriate Fll functional 
groups, Fll transaction sets, and Fll data segments as defined in sections 622 through 6.4.4.3.38, 
inclusive, in response to receipt of Fll functional groups, Fll transactions sets, and Fll data elements, 

• Fll-translators claiming to be conformant shall emit conditional protocol elements when the 
condition is satisfied; 

• Functional Acknowledgments shall be generated before Application Acknowledgments, when 
both are requested. Fit translator, claiming conformance to Class It or IV, shall generate Fll 
acknowledgments before responses to query requests. 
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7.1 . General conformance matters 

Conformance to protocol support, within protocol conformance class I, II, III, and IV, is demonstrated by: 

a. Ability to assemble and disassemble data elements by functional groups and all subordinate 
levels; 

b. Ability to preserve syntax and semantics of the interchange between financial institutions. 



The concept of support is further refined in the Static Requirements clause of this standard. 
7.2. Protocol conformance classes 

There are four static protocol conformance classes. Each protocol conformance class specifies a set of 
functionality by functional group types as follows: 



Table 56 - Conformance classes 





Class 


Functionality 


1 


Financial data 
Image views 

Functional acknowledgments 
Application acknowledgments 


II 


Financial data 
Image views 

-Functional acknowtedaments 






Application acknowledgments 
Query requests (and responses) 


III 


Financial data with security features 

Image views with security features 

Functional acknowledgments with security features 

AppUcation acknowledgments with security features 


IV 


Financial data with security features 

Image views with security features 

Functional acknowledgments with security features 

Application acknowledgments with security features 

Query requests (and responses) with security features 



7.3. Static and dynamic conformance requirements 

Each entity claiming to conform to this standard shall identify the protocol conformance class (listed in 
table 56) to which protocol conformance is claimed. 

The requirements for an implementation claiming to conform to this specification are classified into two 
categories: Static Requirement and Dynamic Requirements. Static requirements relate to the 
standardized Fll structures to which conformance is claimed. Dynamic requirements relate the behavioral 
aspects of requirements set forth in this standard, e.g. f circumstances related to generating notifications, 
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6.4.4.3.27. Restart point indicator 

The <restart_point_indicator> data element conveys a value which Indicates to the receiver of a restart 
query request the point at which the previous query request, referenced in <sublect_refjd>, is to be 
restarted. 

Size: 01/V 
Type: AN 

<restart_polnUndlcator>(01/v) ::= <strtng> 
Value: see 6.1.4.3 

Protocol support Conditional, valid only if the <query_request_type> Is restart request ("3 d ) 
Business usage: Conditional, shall be present if the <query_request_type> is restart request (°3 n ). 

6.4.4.3.28, Search user data present indicator 

The Search Using User Data Segment indicator <search_us!ng_user_data_segment> element conveys 
an indication that a user data segment follows, which supplements the selection criteria specified in the 
query request data segment, and its content is to be used as part of the search criteria. 

The user data selection criteria is carried in a User Data segment as defined in 6.4.2.6. The syntax and 
semantics of contents of the <binary.data> component of the User Data segment are outside the scope 
of this standard. 

Size: 01/01 

Type: N 

<searchzuser_datajre3entJndlcator>(01ffl ~ ~ 

<8udp(_absent> "0" — [DEFAULT] 

<sudpLpresent> ::= "1" 

Values: m Q* means "do not use user data* [DEFAULT]; 
"1 " means "use user data". 

Protocol support Optional 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement 



7. Conformance requirements 

Conformance to this standard means that an implementation supports data elements as defined in this 
standard for the protocol conformance classes for which conformance is claimed. Support in this standard 
relates to the implementations ability to emit, package and preserve data as presented by the user 
application. Support is further refined into support on origination and support on reception of Flls on both 
static and dynamic levels 

The fact that an Implementation claims conformance to this standard does not in any way imply that it 
provides the functionally required by a specific image product, process, or environment 
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Business usage: Conditionai.shall be present only to specify a limit for a generic criterion. 
64.4.3.26. Private locator range 

The Private Locator Range <privateJocator_range> element is used to tailor a search for imaged items 
matching a specific private (non-X9.46 defined) item locator identifier, or falling within a range of item 
locator identifiers. It comprises two subelements: <private_locator_start> and the 
<private_locator_end>. When both subelements are present, then the rang end value shall be greater 
than, or equal, to the start value. 

To search for imaged item(s), or item data, matching a specific item locator identifier, the same value 
shall be present in both <private_locator_start> and <privateJocator_end>. 

<privateJocator_range> ::= [<privatejocator_start>]<us>[<privato_locator_en4>] 

<prtvateJocator_start> (01780) ::= <string> 
<privateJocator_end> (01/80) ::= <string> 

Protocol support: Conditional, valid only when <query_request_type> is set to 2. 

Business usage: Conditional, shall be present only to request a generic search on a specific value or 
range of values, and shall be present only if specified in Banking Practices Agreement 

GAAJ3J26A. Private locator start 

The Private Locator Start <privateJocator_start> data element conveys a single value, or the low-end 
of a range of values, that is known by the originator to be an alternate "key" for locating the desired item's 
view(s). If a value is not specified, then there is no lower limit to anchor the search, i.e., the search will 
begin with the lowest value. 

^Sfce:— 01/80 ~~ "~~ 

Type: AN 

Values: User defined set of string characters. The absence implies that the range is unbounded at 
the lower limit. 

Protocol support: Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion. 
6.4.4.3.26.2. Private locator end 

The Private Locator End <private_locator_end> data element conveys the high-end of a range of 
values, that is privately known by the originator to be an alternate "key" for locating the desired item's 
view(s). 

Size: 01/80 

Type: AN 

Values: User defined set of string characters. The absence implies that the range is unbounded at 
the upper end. It shall be equal to, or greater than, the value of Private Locator Start, when the 
Private Locator Start is present 

Protocol support Optional. 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
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Values: Includes basic character set (6.1 .3.1.), extended character set (6.1.3.2.) and special 
character set. When the Account Number Start is present, the value shall be equal to, or greater 
than, the value of Account Number Start,. 

Protocol support: Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
6.4.4.3.25. Item serial number range 

The Item Serial Number Range <item_seriaLnumber_range> element is used to tailor a search for 
imaged items matching a specific item serial number, or falling within a range of serial numbers. It is 
comprised of two subeiements: <ttem_serial_number_start> and <item_seriaLn umber_end>. When 
both subeiements are present, then the range end value shall be greater than, or equal to, the range start 
value. 

To search for imaged item(s), or item data, matching a specific Hern serial number, the same value shall 
be present in both <Hem_seriaLnumber_start> and <item_seriaLnumber_end >. 

<hem_serial_number_range> ::= [<ftem_seriaLnu mber_ start>] 
<us>{<ftem_8eriai_num ber_end>] 

<ftem_seriaLnumber_start> (01/10) ::= <strlng> 
<ftBm_seriaLnumber_cnd> (01/10) ::= <string> 

Protocol support Conditional, valid only if the <query_request_type> is search request ("2"). 

Business usage: Conditional, shall be present only to request a generic search on a specific value or 
range of values.. 

"67474J3^ST1~ltem serial number start 

The Item Serial Number Start <rtem__seriaLnumber_start> element conveys the low-end of a range of 
Kern serial numbers) to be used in the search. When used in conjunction with a Serial Number End, it 
shall be the beginning of a range of Item serial numbers. If a value is not specified, then there is no tower 
limit to anchor the search, i.e., the search will begin zero. 

Size: 01/10 

Type: AN 

Values: 0 through 9999999999 
Protocol support Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
6.4.4.3.25.2. Item serial number end 

The Item Serial Number End < ttem_serial_number_end> element conveys the high-end of a range of 
item serial numbers to be used in the search. The absence of a value for this element implies that the 
serial number of all items equal to, or greater than, the value of Serial Number Start shall be evaluated by 
the receivers data base filtration process, as constrained by other values In this query request. 

Size: 01/10 

Type: AN 

Values: 0 through 9999999999. It shall be equal to, or greater than, the value of Serial Number 
Start, when the Serial Number Start is present 

Protocol support Optional 
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Size: 01/12 
Type: N 

Values: 0 through 999999999999 (in cents). It shall be equal to, or greater than, the value of 
Amount Start, when the Amount Start is present. 

Protocol support: Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
6.4.4.3.24. Account range 

The Account Range <account_number range> element is used to tailor a search for imaged Items 
matching a specific item account, or falling within a range of accounts. It is comprised of two 
subelements: <account_number_start> and <account__number_end>. When both subelements are 
present, then the range end value shall be greater than, or equal to, the range start value. 

To search for imaged ftem(s), or item data, matching a specific account number, the same value shall be 
present in both <account_number_start> and <account_number_end>. 

<account_number_range> ::= [<account_number_start>]<us>[<account_ number_end>] 

<account_number_start> (01/1 8) ::= <string> 
<account_number_end> (01/18)::= <string> 

Protocol support Conditional, valid only if the <query_request_type> is search request ("2"). 

Business usage: Conditional, shall be present only to request a generic search on a specific value or 
range of values. 

6.4.4U3^Cl. Account number start^^ — — ■ — ■ — — - - 

The Account Number Start <account_number_6tart> element conveys the low-end of a range of 
account numbers) to be used in the search. If used with an end account number, It shall be the beginning 
of a range of account numbers. If a value is not specified, then there is no lower limit to anchor the 
search, i.e., the search will begin with the lowest value in the collating sequence defined by the character 
set in the exchange. 

Size: 01/18 

Type: AN 

Values: Includes basic character set (6.1 .3.1.), extended character set (6.1.3.2.) and special 
character set 

Protocol support: Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
6.4.4.3.24.2. Account number end 

The Account Number End <account_number_end> element conveys the high-end of a range of 
account numbers to be used in the search. The absence of a value for this element Indicates that the 
account number of all items equal to, or greater than, the value of Account Number Start shall be 
evaluated by the receiver's data base filtration process, as constrained by other values in this query 
request 

Size: 01/18 

Type: AN 
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6.4.43.22.2. ECE cycle number end 

The ECE Cycle Number End <ece_cycle_number_end> element conveys the high-end of a range for 
cycle numbers assigned to this item by the ECE institution. It is be provided to convey the upper limit of 
the scope of search. The absence of a value for this element indicates that the cycle number of all items 
equal to, or greater than, the value of ECE Cycle Number Range Start shall be evaluated in by the 
receiver's data base filtration process, as constrained by other values in this query request. 

Size: 01/02 

Type: AN 

Values: 00 through 99. It shall be equal to, or greater than, the value of ECE Cycle Number Start, when 
the ECE Cycle Number Start is present 

Protocol support: Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
6.4.4.3.23. Amount range 

The Amount Range <amount_range> element is used to tailor a search for imaged items matching a 
specific (dollar) amount, or falling within a range of amounts. It is comprised of two subelements: 
<amount_start> and <amount_end>. When both subelements are present, then the range end value 
shall be greater than, or equal to, the range start value. 

To search for imaged item(s), or item data, matching a specific (dollar) amount, the same value shall be 
present in both <amount_start> and the <amount_end>. 

<amount_range> [<amount_start>}<U3>{<amount_end>] 

<samountistart> (01/12) ^^*<3lumeric>~~ , ' ■ - * 88 " ^~ 

<amount_end> (01/12) ::= <numerio 

Protocol support Conditional, valid only if the <query_request_type> is search request ("2"). 

Business usage: Conditional, shall be present only to request a generic search on a specific value or 
range of values.. 

6.4.4.3.23.1. Amount start 

The Amount Start <amount_start> element conveys the low-end of a range for item amounts). If used, 
it shall be the beginning of a range, tf a value is not specified, then there is no lower limit to anchor the 
search, i.e., the search will begin with zero. 

Size: 01/12 

Type: N 

Values: 0 through 999 999 999 999 (in cents) 
Protocol support: Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
6.4.4.3.23*2. Amount end 

The Amount End <amount_end> element conveys the high-end of a range for item amounts. It is used 
only if requesting a range, tt is be provided to convey the upper limit (conveyed in cents) the scope of 
search. The absence of a value for this element indicates that the amount (dollar value) of all items equal 
to, or greater than, the value of Amount Range Start shall be evaluated by the receiver's data base 
filtration process, as constrained by other values in this query request 



132 



COPYRIGHT Amor ic An national Standards Institute 
ViconBod by Information Handling Servicoo 



XP008074623 



X9.46-1997 



6.4.4.3.21.2. ECE sequence number end 

The ECE Sequence Number End <ece_seq_number_end> element conveys the high-end of a range for 
an item number assigned by the institution that created the ECE check detail record associated with an 
imaged item. The absence of a value for this element indicates that the ECE sequence number of all 
items equal to, or greater than, the value of ECE Sequence Number Start shall be evaluated by the 
receiver's data base filtration process, as constrained by other values in this query request. 

Size: 01/15 

Type: AN 

Values: Characters from the set 0..9. It shall be equal to, or greater than, the value of 
ECE Sequence Number Start, when the ECE Sequence Number Start is present. 

Protocol support: Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
6.4.4.3.22. ECE cycle number range 

The ECE Cycle Number Range <ece_cycle_number_range> element is used to tailor a search for 
imaged items matching a specific ECE cycle number, or falling within a range of ECE cycle numbers. It is 
comprised of two subelements: <ece_cycle_number_start> and <ece_cyc!e_number_en<t>. When 
both subelements are present, then the range end value shall be greater than, or equal to, the range start 
value. 

To search for Imaged item(s), or item data, matching a specific ECE cycle number, the same value shall 
be present in both <ece_cyde_number_start> and the <ece_cycle_number_end>. 

<ece__c ycle,num ber_range> ::= [ <ece_cyde_number_start> ] 

<us>[<ece_cycle_number_end>] 

<ece_cycle_number_start> (01/02) :t= <string > 
<ece_cycle_number_end> (01/02) ::= <string > 

Protocol support Conditional, valid only if the <query_requesl_type> is search request ("2"). 

Business usage: Conditional, shall be present only to request a generic search on a specific value or 
range of values. 

6.4.4.3.22.1. ECE Cycle number start 

The ECE Cycle Number Start <ece_cycle_number_start> element conveys the low-end of a range of 
cycle numbers assigned to this item by the ECE institution. If used, It shall be the beginning of a range of 
cycle numbers, if a value is not specified, then there is no lower limit to anchor the search, i.e„ the search 
will begin with zero. 



Size: 01/02 

Type: AN 

Values: 00 through 99 

Protocol support Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
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Protocol support: Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
6.4.4.&20.2. ECE business date end 

The ECE Business Date End <ece_business_date_end> element conveys the high-end of a range of 
business date(s). It is used only if requesting a range. The absence of a value for this element indicates 
that the ECE business date of all items equal to. or greater than, the value of ECE Business Date Start 
shall be evaluated by the receiver's data base filtration process, as constrained by other values in this 
query request. 

Size: 08/08 

Type: AN 

Values: See 6.4.2.8.2. It shall be equal to, or greater than, the value of ECE Business Date Start. 
Protocol support Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
6.4.4.3^1 . ECE sequence number range 

The ECE Sequence Number Range <ecejBeq_numbre_range> element is used to tailor a search for 
imaged items matching a specific ECE sequence number, or falling within a range of ECE sequence 
numbers. It is comprised of two subetements: a <ece_seq_nufnber_start> and a 
<ece_seq_number_end>. When both subelements are present, then the range end value shall be 
greater than, or equal to, the range start value. 

To search for imaged item(s)i or item data, matching a specific ECE sequence number, the-same-value 
shall be present frvboth <ece_seqj^ufnberlstaft> and<eoe_seq_number_end>. 

<ece_seq_number_range> ::= [<ece w seq^umber_start>]<us>[<ece_seq_number_end>] 

<ece_seq_nu mber_start> (01/1 5) :u= <string> 

<ece_seq_number_end> (01/1 5) ::= <string> 

Protocol support Conditional, valid only if the <query_request_type> is search request 02"). 

Business usage: Conditional, shall be present only to request a generic search on a specific value or 
range of values.. 

6.4.4.3.21 .1. ECE sequence number start 

The ECE Sequence Number Start <ece_seq_number_start> element conveys the low-end of a range of 
item numbers assigned by the institution that created the ECE check detail record associated with an 
imaged item. If used, it shall be the beginning of a range of sequence numbers. If a value is not specified, 
then there is no lower limit to anchor the search, i.e., the search will begin with 000000000000000. 

Size: 01/15 

Type: AN 

Values: Characters from the set 0..9. 
Protocol support Optional 

Business usage: Conditional, shall be present only to specify a limit for a generic criterion.. 
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<acceptable_compresslon Jds> ::= <view_compresslon_algo Jd> { <usxvlew_compression_algo Jd> } 
Values: See 6.4.2.8.3.. 
Protocol support: Optional 

Business usage: Conditional, shall be present only to override or supplement Banking Practices 
Agreement. 

6.4.4.3.1 9. Payor bank routing number 

The Payor Bank Routing Number <payor_bank_m> element conveys the routing number to be used in 
the search criteria. If X9.37 is used, this is the Payor Bank Routing Number from the check detail record (type 
25, field 4 and field 5 concatenated). 

The absence indicates that the payor bank name is not used to limit the scope of the search request. 
Size: 09/09 
Type: N 

<payor_banlern>(09/D9) ::= <routing _number> 

Values: 000000000 through 999999999 
Protocol support* Optional 

Business usage: Conditional, shall be present only to request a generic search on a specific value or 
range of values.. 

6.4.4.3.20. ECE business date range 
~P^„ECE Business Date Range-<e «~bus?^^ 



Hmaged-items-rr^tching-arspecmc-business date, or falling within a range" of "busirWss dates, it is 
comprised of two subelements: the <ece_buslness_date_start> and the <ece_business_date end> 
When both subelements are present, then the range end value shaJI be greater than, or equal lo the 
range start value. 1 

To search for imaged item(s), or item data, matching a specific ECE business date, the same value shall 
be present in both <ece_business_date_start> and the <ece_business_date_end>. 

<ece_busness_date_range> ::= t<ece.busness_date_start>]<us>[<ece^busness^date_end>] 

<ece H busness.date_start> (08/08) ::e= <x9_date> 
<ecej>usness_date_ end> (08/08) ::o <x9ldate> 

Protocol support Conditional, valid only if the <query_request__type> is search request ("2"). 

Business usage: Conditional, shall be present only to request a generic search on a specific value or 
range of values.. 

6.4.4.3.20.1. ECE business date start 

The ECE <ece_business_date_start> element conveys the low-end of a range of business date(s) If 
used, the business date start shall be the beginning of a range of dates. If a value is not specified then 
there is no lower limit to anchor the search, i.e., the search will begin with the earliest of the' ECE 
business date known to the user. 

Size: 08/08 

Type: AN 

Values: See 6.4.2.8.2. 



129 



COPYRIGHT American National Standards Institute 
Licensed by intoxmatlon Handling Services 



Best Available Copy 



XP008074623 



X9.46-1997 

6*4.4.3.1 6. Maximum search lapse time 

The Maximum Search Lapse Time <maxjapse_time> element conveys the originator's search (browse) 
lapse time constraint for this request The lapse time is to be honored by the serving Fll-translator and is 
expressed in minutes. 

Should the lapse time expire before all the imaged items are found which match the selection criteria, the 
serving Fll-translator shall return the views matching the criteria to the requestor, and indicate that more 
views are available if known, or indicate that more imaged items may exist that match the selection 
criteria, but the quantity is unknown. 

Size: 01/06 
Type: N 

<maxJapse_time>(01/D6) ::= <numerfo - expressed in seconds 

Values: User determined, 1 to 999999 seconds. 

300 = 300 seconds [DEFAULT] 
999999 = no maximum time limit specified 
0 = not valid 

Protocol support: Optional. 

Business usage: Conditional, shall be present to override the 300 second default.. 
6.4.4.3.17. Maximum matching views requested 

The Maximum Matching Views Requested <max_matching_views_reqd> element conveys an upper 
limit of the number of views requested in the subject query request. 

-if -the-number-of-views-found-ma^^ 

acknowledgment shall be generated indicating the number of views found exceeds the upper limit in the 
associated request The maximum number of views found shall be conveyed in an Item Views functional 
group and a negative acknowledgment shall be conveyed in an Application Acknowledgment functional 
group. 

Size: 01/06 
Type: N 

<max_matching_vtews_reqd><01/06) ::e <numerio 

Values: 0 through 999999 

The value zero for this data element shall mean that ALL views matching the selection criteria are 
to be returned. 

Protocol support Optional 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.4.4.3.1 8. Acceptable compression Identifiers 

The Acceptable Compression Ids <acceptable_compresslonJds> element conveys the compression 
Ids which are acceptable for images returned in response to this request If the receiver of this request is 
unable to satisfy it, the receiver shall send a negative Application Acknowledgment, if one was requested. 

Size: 01/V 

Type: AN 
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<frontal_view> ::= a o° - DEFAULT 

<rear_view> ::= tt 1" 
<frontaLand_rear_vlew> ::= "2" 

Values: 0= frontal view [DEFAULT]; 
1 = rear view; 

2= both frontal and rear views. 
Protocol support Optional. 

Business usage: Conditional, shall be present if the <query request_Jype> is other than a cancel 
request ("0"). 

64.4.3.14. View snippet region 

The View Snippet Region <view_snippet_region> element conveys the desired region of the item's 
image to be snipped. Either the <snippet_name> or <snippet_detall_info> shall be present The 
<snippet_name> is defined in 6.4.2.8.14.1. The <snippet_detailJnfo> comprises three subelements: 
<snlppet_origin>, <snippet_offset>, and <snippet_unit._pf_rneasurement>. These subelements are 
defined in 6.4.2.8.142., 6.4.2.8.14.3., and 6.4.2.8.14.4., respectively. 

Size: 01/31 

Type: AN 

<vfew_snippeUegion><01/31) <snippeL.name> I <snippet_detailJnfo> 
See syntax and semantics in 6.4.2.8.14. 

Protocol support Conditional, valid only when <view_side_requested> is frontal view (tT) or rear view 



Business usage: Conditional, shall be present when a snippet is requested.. 
64.4.3.1 5. Obsoletes query request identifier 

The Obsoletes Query Request Identifier <obsoletes_query_requestJd> element conveys the identity of 
either the transaction set, or the query request data segment that this query request obsoletes. The effect 
of issuing a query request containing this data element is that the named query request being obsoleted 
is canceled by the receiving FM-system-user, and any results returned will refer to the selection criteria 
specified in this query request 

If the value is a transaction set reference identifier, then the query request identifier shall be absent 
Conversely, if the value is query request identifier, then the transaction set reference identifier shall be 
absent. 

Size: 34/92 

Type: N 

<obsoletes_query.requeslLid>(34a2) [ <ts.ref Jd> ] [<us> cqrdjd> ] 

Values: See 6.3.22. for <ts_refjd> and 6.4.4.3.2. for <qrdjd> 
Protocol support: Optional. 

Business usage: Conditional, shall be present to obsolete an outstanding query request. 
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<low> 
<medium> 
<high> 




<user_defiiK*Lpriortty> "2" I "3" I "4" I "6** I "7" \ "6" 

Values: 1 = low priority; 

2,3,4 = reserved for private usage by financial institutions; 
5= medium priority; 

6,7,8 = reserved for private usage by financial institutions; 
9= high priority. 

Protocol support: Conditional, valid only if the <query_request_type> is other than a cancel request 



Business usage: Conditional, shall be present if the <query_request_type> is other than a cancel 
request ("0"). 

6.4.4.3.12. Retain custody indicator 

The Retain Custody indicator <retaln.custody_indicator> data element conveys the requirement of the 
originator that the Fll-system-user, specified in <fiLacK_recipiefrtJd>, either retain or pass the custody 
of the image. 

Rules for custody are specified in regulations such as UCC, Federal Reserve regulations, clearing 
arrangements, or Banking Practices Agreement The party who has custody of an image shall save the 
Image and shall provide the Image whenever requested, until such time as the rules for custody expire or 
the custody is passed. When rules for custody expire or custody is passed, this party no longer is 
required to provide the image when requested. 

Size: 01/01 
Type: N 

<retaln_custodyJndicator>(01/D1)::= <retaln_custody> 1 <pass_custody> 

<retain_custody> :» # 0 - -DEFAULT 
<pass_custody> ::= °1 • 

Values: 0 = retain custody 
1 = pass custody 

Protocol support Conditional, valid only if the <query_request_type> is other than a cancel request 



Business usage: Conditional, shall be present if the <query_request_type> is other than a cancel 



6,4.4.3.1 3. View side requested 

The View Side Requested <view_side_requested> element conveys the requestor's desired orientation 
(Le. ( side or view) for imaged items matching the selection criteria. 

Size: 01/01 

Type: N 

<vtew_8ide_requested>(01 /01 ) <frontal_vtew> I <rear_ytow> I 
<frontal_and_rea r_view> 



CO"). 



ro-> 



request ("0"). 
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Values: 0= electronic format; 
1- tape; 
2= optical disk; 
3= diskette; 

4 = paper copy of item; 

5 = original paper item; 

6 ... 799 = reserved for X9 use; 
800 ... 999 = reserved for private use. 

Pr0t0C0, ^ P ° rt: Conditiona, » valid on, y 11 the <query_request_type> is other than a cancel request 

Business usage: Conditional, shall be present if the <query_request type> is other than a cancel 
request CO"). 

6.4.4.3.10. Transport media requested 

The Transport Media Requested <transport_media_requested> element conveys a value specifying 
how the results of a query are to be transported to the requested use. 

Size: 01/02 

Type: N 

<transporUnedla_requested>(01S02) ::= <elec_comJink> I <hand_courier> I <overnight_mait> I 
<regular_mail> I <fax> I <private_transport> I <reserved_for_x9_trasp_media> 

<elec_com_linlo ::= "Q* - DEFAULT 

<hand_couriet> ::= "1 ■ 

<ovemight_mall> ::= "2" 

----- — <reguler~mait> ::="3 n - 

<privote_transport> n 5"l...l°9° 
<reserved.for^x9_trasp_media>:^ "WL-rw 

Values: 0= electronic communications [DEFAULT]; 
1 = hand courier; 
2= overnight mail; 
3= regular mail; 
4 = fax; 

5 ... 9 = private transport media; 
10 ... 99 = reserved for X9 use. 

Protocol support Optional 

Business usage: Conditional, shall be present if the <query_req uest_ty pe> is other than a cancel 
request ("0"). 

6.4.4.3.1 1 . Processing priority 

The Processing Priority <processing__priority> element conveys desired importance that the originator 
has associated with this request. The receiving system's processing behavior associated with these 
values shall be defined in the Banking Practices Agreement. 

Size: 01/01 

Type: N 

<processlng_priority>(01/01) ::= <low> I <medium> I <high> I <user_defined_priority> 
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1 1 means that the response shall be encrypted and Digitally Signed; 
21 means that the response shall be encrypted and MAC'ed. 

Protocol support Optional 

Business usage: Conditional, shall be present only to specify or to convey security features or security 
mechanisms. 

6.4.4.3.7. Retrieval image key 

The Retrieval Image Keys <retrieval_image_key> element contains the value which represents the 
unique keys of the imaged item(s) to be retrieved. Its syntax and semantics are that of <imagejcey>, 
defined in 6.4.2.5.9. 

Size: 34/V 

Type: AN 

<retrievaljmage_key>(34/v) ::= <imagejcey>[<us><image_key>] 
Value: 6.4.2.5.9 

Protocol support: Conditional, valid only if the <query_request_type> is retrieve request ("1") 
Business usage: Conditional, shall be present if the <query_request_type> is retrieve request CO- 

6.4.4.3.8. Scale size required 

The Scale Size Required <6cale_stze_required> element conveys the required scaling factor that the 
originator has designated for images returned in accordance with this request 

Size: ,01/03 _ ..... _ _ 

Type: N 

<sca!e_sbe_requested>{01 /03) ::= <numerio - represents a percentage (%) 
Values: 01 through 999 

Protocol support Conditional, valid only if the <query request_type> is other than a cancel request 

Business usage: Conditional, shall be present if the <query_request_type> is other than a cancel 
request ("0"). 

6.4.4.3.9. Response media 

The Response Media <respon$e_media> element contains a value indicating the physical type of media 
to be used to convey the results of a query request. 

Size: 01/03 

Type: N 

<response_medla><01 /03) <electrontc_format> 1 <tape> I <optical_dislo I <diskette> I 

<paper_copy_of_item> I <ortgtnalJtem> I <reserved_fof _jc9_melda> I <user_deflned_medla> 

<etectronlc_format> ::= "0" - DEFAULT 

<tape> ::e°r 
<opticaJ_dl3k> m 2 m 

<dlskette> ::s "3° 

<paper_copy_of Jtem> ::= M" 
<©rfginal_rtem> "5" 
<reserved_for _x9_media> "6' I ... I "799" 

<U8er_defined_media> ::= "800"! -PSM" 
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<output_type_requested><01/D1) ::= <KemJnf6_only> I <dtenUnfo_and_user_data> I 
<itemj nf o_and_item _views> I <3ternJn1o_user_data_and_views> I <imageJceys_only> I 
<views_of_ttem_only> 

<ftemjnfo_only> ::= "0* 

<ttem Jnfo_and_user_data> ::= "1 * 
<item_info_and_item _views> ::= "2" 
<rtemJnfo_user_data_and_views> ::= "3" 
<lmageJceys_only> ::= "4" 

<views_of_item_onty> ::= "5" 

Values: 0 Item Information <item_information> only, i.e., no views; 

1 Item Information <item_lnformation> and User Data <user_data> only, i.e., no views of 
imaged items; 

2 Item views <ltem_views> and corresponding Item Information <item Jnformation> only, 
I.e., no User Data; 

3 Item views <item_views> and corresponding Item Information <item_information> f and 
User Data <user_data>; 

4 Image keys only; 

5 Item views <ftem_yiews> only (i.e., no item information). 

Protocol support: Conditional, valid only if the <query_request_type> Is other than a cancel request 

ro°) 

Business usage: Conditional, shall be present if the <query_request_type> is other than a cancel 
request ("0"). 

6.4.4.3.6. Secured results request indicator 

— The Secured Results Request Indicator <s^ 

- — which imficates mat theresultsofth^ 

or Authentication. Data Protection is to be provided by encrypting the results. Non-Repudiation is to be 
achieved by digitally signing the results, and Authentication is to be achieved by creating a MAC code. 
When present this indicator places a requirement upon the receiving Fll-system-user. 

If the receiving Fll-system-user can not perform the requested security service, the request shall not be 
performed. If an Application Acknowledgment was requested, it shall convey that the receiving Fll- 
system-user was unable to perform the request and indicate the appropriate diagnostic code. The choice 
of diagnostic code is dependent upon the local security policy of the receiving Fll-system-user. This data 
element applies to both the Acknowledgment and the response to Query Request. 

Size: 02/02 

Type: N 

<secured_results_request„indicator> (02/02)::= <no_sec_reqd> I <digttal_sign.only> I <macd_onty> I 
<eocryption_onty> I <encryption_digrtal_sign_oniy> I <encryption_and_tnacd_onty> 

<no_sec_reqd> ::= "00 M - DEFAULT 

«tigftaLsign_only> :s= "10" 

<macd_only> ::= "20" 

<encryptlon_on!y> ::= "01 " 

<encryption_dlgitaJ_slgn_only> ::= "1 1 ° 
<encryption_and_macd_only> ::= "21° 

Values: 00 means no security services requested for the results [DEFAULT]; 

10 means that the response shall be Digitally Signed only; 

20 means that the response shall be MAC'ed only; 

01 means that the response shall be encryption only; 
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Business usage: Conditional, shall be present if the <query_request_type> is cancel request ("0°) or 
restart request ("3"). 

6*4.43.4.1 Reference ID type 

The Reference ID Type <ref_id_type> subelement value identifies the type of the reference ID included 
in the Subject Reference ID. 

Size: 01/01 

Type: N 

<ref_jdjype>(01/01) ::= <ts_ref_id> I <qrd_id> I <isd_refjd> I <item_ref_id> 
<ts_refjd> ::= "0" 

<qrd_id> ::= a r 
<isd_ref_id> ::= "2" 

<item_refjd> ::= "3" 

Value: 0= Transaction Set Reference ID; 
1s Query Request ID; 
2= Item Subgroup Reference ID; 
3= item Reference ID. 

Protocol support: Conditional, valid only if the <query_request_type> Is cancel request HFJor restart 
request ("3"). 

Business usage: Conditional, shall be present if the <query_request_type> is cancel request ("0") or 
restart request ("3"). 



6.4.4.3.4.2 Reference ID value 

The Reference ID value <ref Jd_value> subelement contains the actual ID as identified by the 
Reference ID type. 

Size: 20/58 
Type: AN 

<ref_ld_value><20/58)::e <ts_refjd> I <qrdjd> I <dsd_refjd> I <ttem_refjd> 



Value: See 6.3.2.2.for <ts_refjd>, 6.4.4.3.2 for <qrdjd>, 6.4.2.3.2 for <isd_ref_id>, and 6.4.2.5.2 for 
<Hem_refJd> 

Protocol support: Conditional, valid only if the <query_request_type> is cancel request f0")or restart 
request C^*). 

Business usage: Conditional, shall be present if the <queryjrequest_type> is cancel request (XT) or 
restart request ("3"). 



6.44.3.5. Output type requested 

The Output Type Required <output w type_requested> element contains a value which indicates the 
type of results required as the outcome from the Fll-systenvuser satisfying a search request. The 
presence of this element depends upon the value for <query_request_type> being other than a cancel 
request fO"). 
Size: 01/01 

Type: N 
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Local Value: A numeric value created by the originator such that each item subgroup reference 
Identifier in this transaction set shall have a unique value. 

Protocol support: Mandatory 

Business usage: Mandatory 

6.4.4.3.3. Color indicator 

The Color Indicator <color Jndicator> element conveys a value which indicates that item views returned, 
matching the selection criteria, are to be returned as either black and white (BW), or gray-scale images. 



Size: 01/02 
Type: N 

<color_indlcatof>(01/02) ::= <bw_or __gray_scate> I <bw_only>l 

<gray_scale_only> I <bw_ancLgray_sca!e> I <x9_use> I <private_use> 

<bw_or_gray__scale>::= "0" 
<bw_only> ::="1" 
<gray_scale_only> ::= a 2 m 
<bw_and_gray_scate> ::= *3 a 
<x9_use> ::= °4"l ... I "50" 
<private_use> ::= "51 " I ... I -99* 

Values: 0 means either BW or gray scale; 

1 means black and while only; . . . 

2 — means gray scale only; — 5 — 

3 means both BW and gray-scale; 

4 ... 50 reserved for X9 use; 

51 ... 99 reserved for private use. 

Protocol support: Conditional, valid only if the <query request typo is other than a cancel request 

on 

Business usage: Conditional, shall be present if the <query_request_type> is other than a cancel 
request ("0"). 

6.4.4.3.4. Subject reference ID 

The Subject Reference ID value identifies the reference ID which Is the subject of this request The 
<subject^refjd> comprises two subelements <refjd_type> and <refjd_value>. 



Size: 22/60 
Type: AN 

<subjecLrefjd>(22/60)::= <refjd_typexu$xrefjd_va1ue> 
Values: See 6.3.2.2. 

Protocol support Conditional, valid only if the <query_request_type> is cancel request ("0*)or restart 
request ("3°). 
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<acceptable_compressionJds> represent a data base "OR" operation. When taken together, the 
results of the request shall represent the mathematical logical union of both sets of data base operations. 

•Start" indicates the beginning of a range, and end indicates the °en<f of a range. If the start component is 
absent, the range starts at the lowest value. If a value for the "end" component is absent the range 
terminates at the highest value. If a single value is desired, the value of the "start" and "end" components 
shall be identical. Restated in mathematical terms: 

- 'Staff conveys a value 2 the value associated with the requested items; 

- 'End' conveys a value <> the value associated with the requested items. 

6.4.4.3.1 . Query request type 

The Query Request Type <query_request_type> element conveys a value which indicates the type of 
Query Request contained in this segment Four type of Query Requests are defined: Cancel Request, 
Retrieval Request, Search Request, and Restart Request. 

Size: 01/02 

Type: N 

<query_request_type> (01/02) ::= <cancei_request> I <retrteval_request> I <search_request> I 
<restart_request> | <reserved_for_X9_types> I <private_request_types> 



<cance!_request> 


"0" 




<retneval_request> 






<search_req uest> 


"2" 




<restart_request> 


::o "3** 




<res*rved_for_JC9_types> 


!:= "4- 1 1 "50- 




<private^request^types> 


::=s^S1^l^rl *W - 





Values: 0= Cancel request; 
1 = Retrieval request; 
2= Search request; 
3 = Restart request 
4 ... 50= Reserved for X9 use; 
51 ... 99 = Privately agreed types of requests. 

Protocol support Mandatory 

Business usage: Mandatory 

6.4.4.3.2. Query request data Identifier 

The Query Request Data Identifier <qrdjd> element conveys a unique identifier assigned by the 
originator. It may be used by a receiving FH-system-user for acknowledgments, or audit and control 
purposes. 

tt Is constructed by concatenating the value of <ts_refjd>, and a locally determined numeric value. This 
value shall be unique to this transaction set 

Size: 18/50 

Type: AN 

<qrd_ld> (16/50) ::= <ts_ref Jd> ". w <local_vaIue> 

Values: Concatenation of these data elements: 

Transaction set identifier (<ts_refjd>) from 6.3.2.2.; 
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Table 55-QRP: Query request data segment element names 



QRD: Query request data segment 


Size 


Data 


Ret 


Protocol 


Business 


element names 




type 




support 


usage 


<query_requesLdata> 


- 


- 


[QRD] 


- 


_ 


<query_reques|_tvDe> 


01/02 


N 




M 


M 


<qnJJd> 


18/50 


AN 




M 


M 


<s ub]ect_ref_td> 


22/60 


AN 




C12 


R99 


<retrtevaljmage_key> 


34/V 


AN 




CI 4 


B31 


<ootorjndlcator> 


01/02 


N 




08 


©28 


<outp ut_type_requested> 


01/01 


N 




C8 


B28 


<sectired_results_request_indicator> 


02/02 


N 




o 


B9 


<scate„stze„requested> 


01/03 


N 




cs 


aoo 


<response„media> 


01/03 


N 




C8 


ft?9 


<transport_media_requested> 


01/02 


N 




o 


R28 


<processing_prfortty> 


01/01 


N 




C8 


B28 


<retain_custodyJndicator> 


01/01 


N 




C8 


B28 


<obsoJetes_query_requesLid> 


34/92 


AN 




o 


B33 


<maxJapsejime> 


01/06 


N 




o 


334 


<max_matchinfl_vi6ws reqd> 


01/06 


N 




o 




<vtew_sfde_reques*ed> 


01/01 


N 




o 


B28 


<view_snippet_reg'ton> 


01/31 


AN 




CIS 


B32 


<aoceptabfe.compression„ids> 


01 /V 


AN 




o 


B3 


<payor_bank_m> 


09/09 


N 




o 


B35 


< ece_business_ da te /ance> 








C13 


H35 


'<ece^bustnessidateistart> 


~"08rt)8 




— 




R17 


<eoe n business_date_end> 


08/08 


N 




o 


R17 


< ecQ^seouencG number_rnnqe> 








C13 


0*1C 


<eoe_seq_number_ start> 


01/15 


AN 




Q 


Dl f 


<ece_seq_numbe r_ end> 


01/15 


AN 




Q 


R17 

Dl ' 


< QCQ_cyd6_number_rang9> 








C13 


oqc: 


<ece_cyde_number start> 


01/02 


AN 




n 


R17 


<ece_cycte_number_end> 


01/02 


AN 






R17 
Dlf 










C13 


R3S 


ornount^_start> 


01/12 


N 






Rl7 
Dl f 


<amount_end> 


01/12 


N 






R17 
Dl r 


<account_number_ range> 








WllJ 


R35 


^coount_n umbo r_start> 


01/18 


AN 




O 


B17 


<account_number_end> 


01/18 


AN 




o 


B17 


<dtem_S6riaLnumber_(anQe> 








C13 


B35 


<item_serial_number_start> 


01/10 


AN 




O 


B17 


<ftem_seriaLnumber_end> 


01/10 


AN 




0 


B17 


<pnVate_focator ranae> 








C13 


B35+B1 


<p rfvatB_tocator_start> 


01/80 


AN 




O 


B17 


<privateJocator_end> 


01/BO 


AN 




O 


B17 


<restarUpoJnt_lndicator> 


01/V 


AN 




C16 


B10 


<search_user_datajreser^indkator> 


01/01 


N 




O 


B1 



Items matching the range selection criteria result from reoeMng Fll-system-user "ANDing" the values 
when searching the local image and item information base. The values of multi-value data elements, tike 
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Table 54 - QRD: Query request data segment - element assignment 



UnUi uuery icifUotH wsui ovgnreni 


Applicability by 
sbstntct opofotlofi 


Elements names 


Coned 
Request 


Retrieval 
Request 


Search 
Request 


Restart 
Request 


<query_jequesL.data> 




^_ 






<query_request_type> 


Y 


Y 


Y 


Y 


<q rd Jd> 


v 

T 


Y 


v 

T 


Y 


<sub|oct_refJd> 


y 






Y 


<retrievaljmage_key> 




Y 

T 






<oolor.indicator> 




v 

T 


Y 
T 




<outpul.type„requested> 




Y 


Y 


Y 


<secured_resutts_requesUndicator> 




Y 
T 


v 

T 




<scate_siZ6_requ6st8d> 




Y 
T 


Y 
T 




<response_media> 




Y 
T 


V 

T 


Y 


<transport_mecfia_requeste<t> 




v 

T 


v 

T 


Y 


<processing_prtortty> 




Y 
T 


Y 
T 


Y 


<retain„custody„irt(ftcator> 




Y 


Y 




<0b$otetes_query_requestjd> 




Y 


Y 




<maxJapse_tim©> 




Y 


Y 


Y 


<max_matching_views_reqd> 




Y 


Y 


Y 


<v»ew_S!de_requested> 




Y 


Y 




<view„snippe\.rBQton> 




Y 


Y 




<acceptab!G__ccm pression_ids> 




Y 


Y 




<payorJ>ankjn> 






Y 




<ec«_busness_date_rango> 






Y 




<ece„sequenc©_number_range> 






Y 




<ec8_cyde_rttjmber_.range> 






Y 




<amount_range> 






Y 




<aooount n nunTb6r_fange> 






Y 




<ftem_serial_number_range> 






Y 




<prfvatoJocator_range> 






Y 




< resta rt_point_lncflcatof> 








Y 


<sean^_user_data_pf0senUndicator> 






Y 





Y - the data element applies 
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• Restart The ability to restart a query which exceeded specified constraints. 

Table 54 identifies the applicability for mandatory and optional data elements of the Query Request Data 
segment as they apply to these four operations. 
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f. One or more Query Request Data <query_request_loop> structures which contain elements 
corresponding to one query, cancel, or restart operation per iteration of the internal loop. The 
data segments contents may cover a request for a specific imaged item, or a group of imaged 
Hems, which all satisfy the retrieval or search criteria, a request to cancel an outstanding query 
request, transaction set, or functional group, or a request to restart a query which exceeded 
specified constraints; 

g. Conditionally, one Transaction Set Security Trailer <ts_securityjrailer> is the standard 
security trailer which indicates the bounds of the <ts_security_header> . It may contain a MAC 
code, if that was the form of authentication applied to this transaction set Its syntax is defined in 
6.3.1.10; 

h. One Transaction Set Trailer <transjsetJraUer> which identifies the end of this transaction set 
Its syntax is as defined in X 12.22 tobeaGE segment, and included in this standard in 6.3. 12. 

6.4.4.2. Query request loop 

The <query_request_loop> segment enables the exchange of standardized query request selection 
criteria and non-standard, privately agreed, user defined selection criteria. Each instance of the loop in 
the interchange shall be evaluated on its own merit The syntax of this loop shall be structured as 
specified in table 53. 

Protocol support Mandatory 

Business usage: Mandatory 



Table S3 * Query request loop element names 



Query request loop 
element names 


Ste 


Data 
type 


Ref. 


Protocol 
support 


Business 
support 














~<query-requestJoop> 












<doop„hoader> 






LS 


M 


M 


<query_request_data> 






[QRD] 


M 


M 


<user_data> 






BIN 


O 


B1 


4oop„traner> 






LE 


M 


M 


1) 10,000 maximum loop iteration 











The components of each instance of an Item Subgroup loop are as follows: 

• One Loop Header <loopJheader> segment defined in 6.3. 1.5. The value of <loopJd> shall be 
V; 

• One Query request <query_request_data> segment Its syntax is defined in 6.4.2.5; 

• Optionally, one User Data <user_data>, whose syntax is defined in 6.42.6. A User Data 
segment is an alias for a Bin Segment It b provided to carry a privately agreed stream of data. It 
conveys a bi-laterally agreed formatted contents for Query Requests functions whose syntax, 
and semantics, are outside of the scope of this standard; 

• One Loop Trailer <toop_traitet> segment defined in 6.3. 1.6. The value of <toopJd> shall be 1 " 



6.4.4.3. Query request data segment 

The <query request data> segment supports four functions: 

• Cancel: The ability to cancel an outstanding query request, transaction set, or functional group; 

• Retrieval: The ability to specify a named image, item or a list of specifically named image items for 
retrieval; 

• Search: The ability to search for imaged items, which meet specified selection criteria; 
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6.4.4.1. Query requests transaction set 

The Query Requests transaction set <query_requestsjts> structure provides for the following requests: 

• Retrieval of one or more imaged items based on an image key, or list of image keys 
(<retrieval_request>); 

• Retrieval of one or more imaged items based on user defined selection criteria (<searcb__request>); 

• Cancel an outstanding query search request, query retrieval request, or previously sent transaction set 
of either financial data or item views (<cancel_request>); 

• Restart a previous query search request, or query retrieval request which has been terminated because 
of constraints exceeded (<restart_request>). 

Protocol support Mandatory 
Business usage: Mandatory 



Table 52 - Query requests transaction set element names 



Query requests transaction set 


Sbe 


Data 


Ref. 


flint n nnl 

rTOlOCvl 


Business 


element names 




type 




support 


support 


<query_requests_ts> 












<trans_satj*eader> 






ST 


M 


M 


<ts_securtty_header> 






S2S 


0 


B9 


<signature_data> 






fSIGl 


o 


B9 


<signature> 






BIN 


C6 


B9 


<gen8(al_RLextensions> 






roroi 


M 


M 


<Query_re<iue$i_toop> 1 












<ts„security„traiter> 






S2E 


CI 


B9 


<trans_set_tra3er> 






SE 


M 


M 



1 - Maximum loop iterations are 10,000 



Each Query Request Transaction Set <query_request_ts> comprises the following structures: 

a One Transaction Set Header <trans_set_header> is an envelope structure compliant with 

X1222 standard, GS, and 1$ defined in this standard in 6.3. 1. 1. The value of the <transjeetjd> 
component of <trans_set_header> shall be "OTS*, indicating that the transaction set contains 
one, or more, specific query requests; 

b. Optionally, one Transaction Set Security Header <ts_secur1ty_header> which conveys 
information about the data protection, or simple authentication mechanisms, applied to the 
transaction set It is used for verifying the integrity of the transaction sets contents, or for decrypt 
the transaction sefs encrypted contents. The security group is defined in 6.3. 1.9; 

c. Optionally, one Signature Data <signature_data> segment which conveys information about the 
digital signature applied to this transaction set, as created by the originating financial institution. 
When present, it enables the receiving Fit-translator, or Fll-system-user, to reconstitute the 
digital signature to verify its authenticity, or to detect if the transaction set contents were altered 
in transit Its syntax is defined in 6.3. 1. 132; 

d. Conditionally, one Signature <signature> segment which conveys the actual digital signature 
identified in <signature_data>. Its syntax is a BIN segment which is specified in 6.3. 1.1 1; 

e. One General Fll Extensions <generaLFiLextension$> segment, whose syntax is defined in 
6.3.2 of this specification; 
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Restart requests provide a means to request that a previous terminated query request be restarted at the 
point of termination. 

The Query Request function may be constrained by supplying service control instructions in the request 
The control instructions may include the scope, or run-time, that the user expects the receiver to respect 
when processing a specific search request 

The functional group shall contain at least one instance of <query_requests_ts>. However, if the 
<testJndicator> in the ISA header is set to TRUE, including <query_requests_ts> is optional. 

The syntax of the <query_requests_fg> shall be as specified in the following table. 



Table 51 - Query requests FG element names 



Query requests FG 


Size 


Data 


Ret 


Protocol 


Business 


element names 




type 




support 


usage 


<queiy_requ8stsjg> 












<fq_header> 






GS 


M 


M 


<fg_securtty_header> 






SIS 


o 


89 


<sJgnature ts> 








0 


B9 










M 


M 


<fg_security tra!ler> 






S1E 


CI 


B9 








GE 


u 


M 



Each Query Requests functional Group <query_requests_fg> comprises the following structures: 

a. One Functional Group Header <fg_header> structure identifies the functional group, and is 
— defined j n 6r3r1r1— The value of <tonc^ — 

73* to indicate that this functional group contains one or more Query Request transaction sets; 

b. Optionally, one Functional Group Security Header <fg_security_header> structure which 
conveys mechanisms which provide simple authentication sen/ices to verify the contents of the 
entire functional group's originator, or to Identify the method of data protection applied to the 
contents of the functional group. The Functional Group Security Header is defined in 6.3.1.7; 

Optionally, one signature transaction set <signaturejts> structure which provides a mechanism 
to apply strong authentication to the transaction sets contents. This structure conveys a digital 
signature applied to this transaction sets contents as created by the originating financial 
institution, and information on how the signature was created. When present, the signature 
enables a receiving Fll-system-user to authenticate the source of the signed data. Its syntax is 
defined in 6.3.1.13.1; 

One or more Query Requests Transaction Set <query_requests_ts> structures which contains 
elements corresponding to one or more query, or cancel operations. Each instance of its 
contents conveys a request for a specific imaged object item, or a group of items, meeting the 
selection criteria, or a request that an outstanding Query Request be canceled. There may be 
one or more query request transaction sets conveyed in a single Query Requests functional 
group. Each instance of a query Cancel Request shall contain a request to cancel a single 
outstanding Query Request. The transaction set may only be absent when the functional group 
is included in a test interchange; 

Conditionally, one Functional Group Security Trailer <fg_securftyjrailer> is the standard 
security trailer, as specified in X1222 and X12.56. Its syntax is defined In 6.3. 1.8; 

One Functional Group Trailer <fg_trailer> identifies the end this functional group. Its syntax is 
as defined in X12J22 tobeaGE segment, and included in this Standard in 6.3. 1.2. 



e. 
f. 
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Protocol support: Conditional, valid only when the acknowledgement is in response to a query request 
other than Query Cancel Request 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement. 

6.4.3.1.13. Restart point indicator 

The <restart_point_indicator> data element is generated by the originator of the Application 
Acknowledgment and contains a value which indicates the point at which the previous query request, 
referenced in <subject__ref Jd>, is to be restarted.. 

Size: 01/V 
Type: AN 

<restart_p©int_lndicator>{01Av) <string> 
Values: see 6.1. 4.3.. 

Protocol support: Conditional, valid only if <appllcation_ack_diagnostic_code> indicates that 
constraints have been exceeded ("8"). 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.4.4. Query requests functional group 

The Query Requests functional group supports a request for item data and images associated with an 
item. This information is to be used by the receiver to identify requested images held in its local data and 
image_store,_orJo_cancel.outstanding query request^ 

Four types of Query Requests functions are distinguished: 

a) cancel request: 

A cancel request provides a means of specifying the sender's request to cancel an outstanding query 
request by specifying the transaction set identifier of the outstanding query request; 

b) retrieve request: retrieve a specific imaged item(s) request 

A Query retrieve request provides a means to request item information, user data or views of a specific 
imaged item by specifying its image keys. Multiple keys may be included to request multiple items. 
The results corresponding to the named imaged item(s) are returned to the requestor in an Item Views 
functional group. ; 

c) general search: general search request that returns images or item data for all items found matching a 
set of selection criteria: 

General search requests provide a means to request a search and retrieve based on the logical 
"AND"ing of the element values specified. If the requestor wants to specify element values in an "OR" 
relationship, multiple query request data segments are used. Selection criteria may be performed: 

• by item: a search request indicating that only a list of image keys is requested causes an 
acknowledgment to be returned that contains a listing (and count) of the imaged item keys that 
satisfy the selection criteria, not the images themselves. 

• by name of item: a search request indicating that imaged items, or item data, or user data is to be 
retrieved, causes the Item Views functional group to be generated for those imaged items that meet 
the specified selection criteria 

d) restart: restart a previous query request which had been terminated because some of the specified 
constraints were exceeded 
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Type: AN 

<sub]ect_qrd Jd>(1 8/50) ::= <qrd Jd>- to acknowledge at the query request level 

Values: See 6.4.4.3.2. 

Protocol support Conditional, present only If requested to be acknowledged at the this level. If used, 
either the <subjeet_ts_refjd>, <subjectjsd_ref_ld>, <subjectjtem_ref_id>, 
<subjecUtem_view_id>, or <subject_qrd_ld>, shall be present. The presence of more than 
one of these shall be considered a protocol violation.. 

Business usage: Conditional, shall be present only if specified In BPA, and then shall be subject to the 
type of acknowledgment requested.. 

6.4.3.1 .1 0. Number Items matching criteria 

The Number Items Matching Criteria <numberjtems_matching_crfteria> element conveys the number 
of imaged item views that were found matching the query request's search selection criteria. 

Size: 01/06 
Type: N 

<number w ltems_inatching.criteria>(01/06) ::= <numerio 
Values: 0 through 999999. 

Protocol support valid only when the acknowledgement is in response to a query request other than 

Query Cancel Request ("0"). 
Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 

Agreement. 

643;1;1 i~. Supplementary Information - -■ ~= — 

The Supplementary Information <8uppIementalJnfo> element further amplifies the application 
acknowledgment diagnostic codes. It could convey the value of the sub-view's compression-id parameter 
that the receiving Fll-translator can not accept, or advise a list of acceptable compression-ids. 

Size: 01/80 
Type: AN 

<supptementaljnfo>(01/$0) <string> 
Values: User defined 
Protocol support Optional. 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement 
6.4.3.1.12. Image keys matching criteria 

The Image Keys Matching Criteria <fnugejcey$_matchlng_crfterla> element conveys the unique 
names (image keys) of imaged items that were found matching the query request's list selection criteria 

Size: 34/V 
Type: AN 

<image_keys_inatchin<ucriteria><34/v) ::= 4mage_key> { <usximagejcey> ) 
Values: See 6.4^.5.9 
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Protocol support: Conditional, present only If requested to be acknowledged at the this level. If used, 
either the <subjecLts_refJd>, <$ubjectjsd_ref_id>, <subject_item_refjd>, 
<subject_item_viewjd>, or <subject_qrdjd>, shall be present. The presence of more than 
one of these shall be considered a protocol violation.. 

Business usage: Conditional, shall be present only if specified in BPA, and then shall be subject to the 
type of acknowledgment requested.. 

6.4.3.1.7. Subject item reference identifier 

The Subject Item Reference Identifier <subjectjtem_refjd> element conveys the unique identifier that 
was assigned to the collection of views associated with a single subject item to which this 
acknowledgment refers. 

The syntax of <subjectjtem_ref_id> is that of <item_refjd> defined in 6.4.2.5.2 of this specification. 
Size: 20/58 
Type: AN 

<subjectJtem_inefJd><20/58) ::= <ftem_ref _id>- to acknowledge at the imaged item /eve/ 
Values: See 6.4.2.5.2 

Protocol support: Conditional, present only If requested to be acknowledged at the this level. If used, 
either the <$ubject w ts_refjd>, <subject_lsd_refjd>, <subjecUtem_refJd>, 
<$ubject_item_viewjd> l or <subject_qrd_id>, shall be present. The presence of more than 
one of these shall be considered a protocol violation.. 

Business usage: Conditional, shall be present only if specified in BPA, and then shall be subject to the 
type of acknowledgment requested.. 

rCtJ3.1JBL— '— SubjeS item view reference identifier ' • - ^ — — — ^— — = — — — 

The Subject Item View Reference Identifier <subjectjtem_view_!d> element conveys the unique 
identifier that has been assigned to the subject view (of an item) to which this acknowledgment refers. 

The syntax of <subject_ftem_viewjd> is that of <ftem_vtewjd> which is defined in 6.4.2.8.1. of this 
specification. 

Size: 22/66 
Type: AN 

<sub]ectJtem_viewJd>{22/66) ::= <item.viewjd>- to acknowledge at the item view level 
Values: See 6.4.2.8.1. 

Protocol support: Conditional, present only If requested to be acknowledged at the this level. If used, 
either the <subject_ts_ref_id> f <subject_isd_refjd>, <subjectjtem_refjd>, 
<subject_item_yiewjd>, or <subject_qrdjd>, shall be present The presence of more than 
one of these shall be considered a protocol violation.. 

Business usage: . Conditional, shall be present only if specified in BPA, and then shall be subject to the 
type of acknowledgment requested.. 

6.4.3.1 .9. Subject query request Identifier 

The Subject Query Request Identifier <subject_qrd_id> element conveys the unique identifier that has 
been assigned to the subject query request, to which this acknowledgment refers. 

The syntax of <$ubject_qrdjd> is that of <qrd_id> which is defined in 6.4.4.3.2. of this specification. 
Size: 18/50 
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<ouLofJ>alance> 
<anived_too_late> 
<constraints_exceeded> 
<unwUKng_to_perform> 




<dc_reserved_ forJC9_use> ■10°l...r499* 
<user_defined_diagnostic_codes> ::= "500 t, l«.l t> 999" 



Values: 0= no error, 

1 = security failure; 

2= Protocol violation; 

3= Banking Practices Agreement violation; 

4 = Unable to locate; 

5 = Image format error; 
6= out of balance; 
7= arrived to late; 

8= constraints exceeded; 

9= unwilling to perform;. 

10 ... 499 = reserved for X9 use; 

500 ... 999 a user defined diagnostic codes. 

Protocol support: Mandatory 

Business usage: Mandatory 

6.4.3.1 S. Subject transaction set reference identifier 

The Subject Transaction Set Reference Identifier <subject_ts_refjd>, element conveys the unique 
identifier that was assigned to the subject -transaction set to which this ac^ 

The syntax of <subject__ts_ref Jd> Is that of <ts_refjd>, which is defined in 6.3.2.2. of this specification. 
Size: 16/42 



Values: see 6.3.2.2. 

Protocol support: Conditional, present only If requested to be acknowledged at the this level. If used, 
either the <subject_ts_refjd>, <8ubject_isd_refjd>, <subject_item_ref Jd>, 
<subject_item.vlew.id>. or <subject_qrd Jd>, shall be present. The presence of more than 
one of these shall be considered a protocol violation.. 

Business usage: Conditional, shall be present only if specified in BPA, and then shall be subject to the 
type of acknowledgment requested.. 

6.4.3.1 .6. Subject item subgroup reference identifier 

The Subject Item Subgroup Information Reference identifier <subject_isd_ref Jd> element conveys the 
unique identifier that was assigned to a group of items, to which this acknowledgment refers. 

The syntax of <subjectjsd_refjd> is that of <isd_ref_id> ( defined In 6.4.2.3.2. of this specification. 

Size: 16/50 

Type: AN 

<sub)ectjsd_ref Jd>(ia/50) ::= <isd_refjd> - to acknowledge at the group of items level 
Values: See 6.4.2.3.2. 



Type: AN 

<subject_ts_ref Jd>{1 6/42) 



::o <ts_refjd>- fo acknowledge at the transaction set level 
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<appllcatton_ack.created.dateJime>{15n5) ::= <x9_datexusxllme> - time is constrained to HHMMSS 
Values: YYYYMMDD<us>HHMMSS Date and time acknowledgment was created 
Protocol support: Mandatory ' 
Business usage: Mandatory 



The Application Acknowledgment Reason Code <application_aclurea$on_code> element conveys the 
reason code assigned by the originator of this acknowledgment. The reason may be further clarified by 
using the <application_ack_diagnostic_code> field. 

Size: 01/01 

Type: N 

<application_aclereason_code><01/01 ) <accepted> I 
<results_of_aJist_request> I <rejected_referenced_ts> I <failure_of_operation> 
<accepted> °o° 
<results_.of v aJist_request> ::= "1° 
<rejected_referenced_ts> ::= "2° 
<failure_of_ operation> °3 M 

Values: 0 Accepted referenced functional group, transaction set, item, or view; 

1 Results of a list request; 

2 Rejected referenced functional group, transaction set, item, or view; 

3 Failure of operation. 

-Protocol support: Mandatory ~__ 

Business usage: Mandatory 
6.4.3.1 A 



The Application Acknowledgment Diagnostic Code <application_ack_diagnostic_code> element 
conveys a diagnostic code that further clarifies the reason code value found in the 
<app(ication_ack_reason_code> field. 

Size: 01/03 

Type: N 

<application_acK_diagnostic_code><01/03) ::= 
<no_em>r> I <security_fai!ure> I <protocol_vio!ation> 

<bpa_vlolatlon> I <unable_to Jocate> I <fmage_format_error> I <out_of_balance> I 

<arrtved JooJate> I <constralnts_exceeded> I <unwDling_to_perform> I <dc_reserved for X9 use> I 

<user_defined_dlagnostic_codes> ~ 



6.4.3.1.3. 



Application acknowledgment reason code 



Application acknowledgment diagnostic code 



<no_error> 

<securfty_tai1ure> 

<protocoLviolation> 

<bpa_viotation> 

<unable_toJocate> 

«dmageJormat_erTor> 

<out_of_balance> 




for reason code = <accepted> only 
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• One Transaction Set Header < trans_set_header> segment, whose syntax is defined in 
6.3. 1.3. The value of <tran$__seUd> shali be m ATS" and it indicates that this is an 
application acknowledgment transaction set; 

• Optionally, one Transaction Set Security Header <ts_security_header> segment whose 
syntax is defined in 6.3.1.7; 

• Optionally, one Signature Data <signature_data> segment, whose syntax is defined in 
6.3.1.13.2; 

• Conditionally, one Signature <signature> segment, whose syntax is defined in 6.3. 1. 1 1; 

• One General Fll Extensions <generaLFlLextenslons> segment whose syntax is defined in 
6.3.2; 

• One or more. Acknowledgment Data Segment <apptication_ack_data> segment, 

• Conditionally, one Transaction Set Security Trailer <ts_security_trailer> segment, whose 
syntax is defined in 6.3. 1. 10; 

• One Functional Group Trailer < trans_setjraiter> t whose syntax is defined in 6.3. 1.4 



6.4.3.1 .1 Application acknowledgment Data 

The application acknowledgment data (<appltcation_ack_data>) provides the actual acknowledgment 
details. Acknowledgment may be either positive or negative. In the case of negative acknowledgments, a 
diagnostic code shall be provided. This segment shall also be used to convey the number of views that 
were found meeting the originator's selection criteria for a Query Request Search operational request. 

Protocol support Mandatory 

Business usage: Mandatory 

Table 50 - ADS: Application acknowledgment data segment element names 



~ AOS: Application acfcnowtedgmem 

data element names 




_ Data- 


— Ret— 


— Protocol — 
support 


-Business- 




type 


usage 


<appiicatjori_ack„<Jata> 






[ADS] 






<appUcatton_acK-createdjctate_.time> 


15/15 


AN 




M 


M 


<appflcation_acJureason„co<le> 


01A1 


N 




M 


M 


<apprtcationjftcK.diaqno5tic_code> 


01A03 


N 




M 


M 


<subiect_ts_ref_id> 


16/42 


AN 




C7 


830 


<sutoiecO$d_refJd> 


18/50 


AN 




C7 


B30 


<subiecUtem_refJd> 


20/58 


AN 




C7 


B30 


<subjecUtem_viewJd> 


22/66 


AN 




C7 


B30 


<subieci_qidjd> 


IB/50 


AN 




C7 


B30 


<numbGr_rtems_match]ng_crtt0rta> 


01A36 


N 




C22 


B2 


<suppt6fnenta)_Jnfo> 


01/80 


AN 




O 


B1 


<tmage„keysjnatchin9_criterta> 


34/V 


AN 




C22 


B2 


<iBSt&ft_j>oint_indlc&tor> 


01 N 


AN 




C17 


B2 



6.4.3.1 JSL Application acknowledgment created date and time 

The Application Acknowledgment Created Date And Time <appllcation_ack_created_date_time> 
element conveys the business date and time of the creation of this acknowledgment 

Size: 15/15 

Type: AN 
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Table 48 - Application acknowtedgment functional group element names 



HHpucBuon AciuiOwi eag meni rv» 


size 


Data 


Ref. 


Protocol 


Business 


element names 




type 




support 


usage 


<appticafion_ack_rq> 












<fa_header> 






GS 


M 


M 


<ffl_securfty_head e r> 






S1S 


0 


B9 


<signature n ts> 








0 


69 


<apptication ack ts> 








M 


M 


<fg_security_trai!er> 






S1E 


C1 


69 


<fg_traUer> 






GE 


M 


M 



The Application Acknowledgment Functional Group is composed of the following elements: 

• One Functional Group Header <fg_header>, defined in 6.3. 1. 1; The value of 
<funtional__groupJd> shall be"72 m , indicating that it is an Application Acknowledgment 
Functional Group; 

• Optionally, one Functional Group Security Header <fg_security_header> t defined in 
6.3.1.7; 

• Optionally, one Signature Transaction Set <sfgnatune_t$>, defined in 6.3. 1. 13. 1; 

• One or more Application Acknowledgment Transaction Set <apptlcationjackJts>; 

• Optionally, one Functional Group Security Trailer <fg_security_traiter>, defined in 6.3. 1.8; 

• One Functional Group Trailer <tfgjraller>, defined In 6.3. 1.2. 



6A3-1. Application acknowledgment transaction set 



The Application Acknowledgment Transaction Set (<application_ack__ts>) provides the Fll-system-user's 
actual acceptance, or rejection, of the interchange contents. An Application Acknowledgment may be 
either positive or negative. In the case of negative acknowledgments, a diagnostic code shall be provided. 
In the case of positive acknowledgments, this transaction set also shall be used to convey the number 
(and optional list) of views that were found meeting the originator's selection criteria for a Query Request: 
Retrieve (only) Keys operational request 

Protocol support: Mandatory 
Business usage: Mandatory 



Table 49 - Application Acknowledgment transaction set element names 



AppOcatlon Acknowledgment 
transaction set element names 


Size 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<appQcatfonackJts> 












<trans_set.neader> 






ST 


M 


M 


<trans_security_header> 








o 


69 


<sfgnature_data> 






fSIGJ 


o 


B9 


<stgnature> 






BIN 


06 


69 


<9eneral.FILextensiorts> 






fGFOI 


M 


M 


<appfication_ack_data> 






TADS1 


M 


M 


<ts_securtty_trafler> 






S2E 


CI 


69 


<trans_set_trailer> 






GE 


M 


M 



The components of the application acknowledgment transaction set are as follows: 
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<vfew_description>(01/32) ::= <string> 

Values: User determined, composed of printable string characters. 
Protocol support: Optional 

Business usage: Conditional, shall be present only If specified in Banking Practices Agreement. 
6.4.2.8.1 9. Scanner manufacturer name 

The Scanner Manufacturer Name <scannerjmfgr_name> element conveys the name of the 
manufacturer of the scanner system. 

Size: 01/30 

Type: AN 

<scannerjnfgr_name><01/30) ::= <string> 

Values: User determined, composed of printable string characters. 
Protocol support: Optional 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement. 
6AJZJU2Q. Scanner model name 

The Scanner Model Name <scanner_modeLname> element conveys the model name and number of 
the scanner. 

Size: 01/15 

Type: AN 

<scanneT jwieLname>(01 1\ 5) <string> 

Values: User determined, composed of printable string characters. 
Protocol support: Optional 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement 
6.4.2.&21 . View capture software 

The Image Capture Software Identifier <view_capture_software> element conveys the name and 
release of software package that created the view. 

Size: 01/30 

Type: AN 

<view_capture_software Jd><01 /30) ::= <string> 

Values: User determined, composed of printable string characters. 

Protocol support: Optional 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement 
6.4.3. Application acknowledgment functional group 

An Application Acknowledgment Functional Group <applicatiorv-ackJg> Is the information object 
exchanged between financial institutions to signal acceptance of responsibility for an Fll. It is defined to 
be a single data structure. The elements of the data structure identify the reference interchange and 
other relevant descriptive information, and an acceptance/reject code. 

The Application Acknowledgment Functional Group is returned as DEFAULT for negative conditions and 
when requested by the originator of the subject interchange. 
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<embeddedjieaderjndicator>(01/03) 
<resetvcd_for_x9> I <private_use> 



::s <spiff> | <ansL aOm_oda> I <tiff_6> I <loca_fs.11> I 



<spiff> 

<ansl_aiim_oda> 

<tiffj6> 

<doca_fs_11> 

<reserved_for_x9> 

<private_use> 



:= T 
:= "2 U 
:= n 3 M 

:= "4" I ^ I "499" 
:= "500" I ... I -099 w 



Values: 0 = Still Picture Interchange File Format 

1 = ANSI/AIIM ODA MS-53 

2 = TIFF 6.0 

3 = I OCA Function Set 1 1 

4 - 499 = Reserved for X9 

500-999- reserved for private use (see Banking Practices Agreement); will not be used by X9. 
Protocol support: Mandatory 
Business usage: Mandatory 
6.4.2.8.16.2 View raster data offset 

The View Raster Data Offset element conveys the number of bytes that precede the image raster data 
that is carried in the BIN segment. The View Raster Data Offset element shall correspond to the 
<embedded_header_indicator>. 

Size: 01/08 

Type: N • - - -- 

<view_raster_data_offset><01/08) :: = <numerio 
Values: 0 through 99999999. 
Protocol support Mandatory 
Business usage: Mandatory 
6.4.2.8.17. Creation computer 

The Creation Computer <creation_computer> element conveys the system name of the originator's host 
computer that was used to create and digitize the imaging data. 

Size: 01/32 

Type: AN 

<creation_eoniputer>(01£32) <string> 

Values: User determined, composed of printable string characters. 

Protocol support Optional 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement. 
6.4.2*8.18. View description 

The View Description <view_description> element conveys the originator's comment, or title, related to 
the imaged item. 

Size: 01/32 

Type: AN 
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Figure 15 - Illustration of the clipping concept 

Size: 04/43 (for each sub-component, i.e., offset value) 
Type: AN 

<clipplng_offset><04/43)::= [ <h1> ] <us> [ <h2> ] <us> [ <v1> ] <us> [ <v2> ] 
<h1>(01/10) ::= <numerio - Measured in PIXELS - DEFAULT = 1 

<h2>(01/10) <numerio - Measured in PIXELs - DEFAULT* view's maximum horizontal dimension 
<v1>(01/10) ::= <numerio - Measured in PIXELS - DEFAULT* 1 

<v2><01fl0) ::= <numerio - Measured in PIXELS - DEFAULT* wow's maximum vertical dimension 

Subetement Values: <tv,>, <h2>. <v t >, <V2>, at least one shall be present 

<h t > is less than <hj> 
<v t > is less than <Vj> 

Absence of a subelement implies that the corresponding vatue is defaulted in accordance with the 

following default table: 

<ht> = 1 [DEFAULT}* 

<h2> = view's maximum horizontal dimension; 

<Vt> = 1 [DEFAULT]] 

<Vjj> = view's maximum vertical dimension. 

The default value for <t>2> and <v 2 > is determined by the either <pixel_perjines> or 
<number_ofJines> depending upon the value of <orientation> defined in 6.4.2.8.6, 6.4.2.8.7 and 
6.4.2.8.13 respectively. When the <orientation> is 1 through 4 then the default value for <hj> is the 
value of <pixel_perjlnes> otherwise It is the value of <number.ofJmes>. When the <orientation> is 1 
^mrough-4, flientfe-defauK 
<pbcel _perjlnes >. 

Protocol support Optional. 

Business usage: Conditional, shall be present when <d!pplng_info> are conveyed.. 
6.4.2.8.16 Embedded header Information 

Embedded Header Information conveys two pieces of information: the <ernbedded_headerJndlcator> 
and <view_raster_data_offset>. The absence of the Embedded Header Information shall be 
understood To mean that an embedded header is not present 
<embedded_headerJrtfo> ::= <embedded Jteader Jndicatof><us><vlew_ias^ 
Protocol support Optional 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement 
64.2.8.16.1 Embedded header indicator 

The Embedded Header Indicator <embedded_headerJrtdicator> element conveys an indication that 
non-raster information is carried in a section of the BIN segments <binary> component. When present, 
an embedded header shall precede the raster data. The value set for this element and the value of 
<view_raster_data_offset> shall correspond. 

Size: 01/03 
Type: N 
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Type: N 

<clipping_origin>{01/01) ::= <top_right_corner_oUmaged Jtem> I 

<top Jeft_corner_of .imaged Jtem> I <bottom_right_comer_ofJmaged_item> ! 
<bottom.lefLcomer_ofJmaged.item> 

<top_righ|_comer_ofjniagedjtein> ::= 

<topjeft_corner_of_imaged_item> ::= "2" 
<bottom_right_corner_ofJmagedJtem> "3° 

<bottomJeft_comer_of_imaged.item> ::= "4" 

Values: 1 = top right comer 

2 = top left comer 

3 = bottom right comer 

4 = bottom left comer 

Note - Top, bottom, left, and right apply to a view which presents a visually correct orientation. 
Protocol support: Optional. 

Business usage: Conditional, shall be present when <clippingJnfo> are conveyed.. 
6.4.2.8.15.2. Clipping offset 

The Clipping Offset <clipping_offset> compound element contains four subelements which convey the 
clipping rectangle's offsets In both horizontal (h) and vertical (v) directions relative to that comer pixel of 
the view defined by the <clipping_origin> element The value of each offset is expressed In units of 
pixels and is a positive number (positive X and Y values include the center of the reference object). The 
offset values collectively establish the bounding sides of the clipping rectangle. 

Pixels on the boundary of the clipping rectangle are included in the selected array of pixels. That is, the 
first pixel of the selected array is at offset (h 1 , v,) and the last pixel of the selected array is at offset (h^ 



The comer pixel at the origin of the full item view is assumed to have an offset value of (1 ,1). Thus, the 
pixel diagonally adjacent to the comer pixel has an offset value of (2,2). 

The following figure illustrates the concept (using <clipping_origin> « 1 as an example). In this figure the 
entire object is represented by dots. The shaded portion identifies the region of interest and the unshaded 
portion identifies the portion to be ignored. 




Figure 15 - Illustration of the clipping concept 
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<x1 _offeet><01 fOS) ::= <decimal„number> 

<x2_offset><01/06) ::a <decimal_number> 

<y1_offset>(01/06) ::= <decimaLnumber> 

<y2_otfset>{01 /06) ::= <decimal_number> 

Values: <x1_offset>, <x2_offset>, <y1_offset>, <y2_oflset> which may be either a positive integer 
or a positive decimal number. 

Protocol support Conditional, valid only in a Item Group Transaction Set. 

Business usage: Conditional, shall be present if necessary to identify properly the snippet. 

6.4^8.14.4. Snippet units of measure 

The Snippet Units Of Measure <snippet_unrts_oLmeasure> subelement conveys the metrics of the 
snippers offset coordinates. The metrics shall be expressed in terms of inches or centimeters. 

Size: 01/01 

Type: N 

<snippeLunits_oLmeasure> <unfts_oUneasure> 

Values: 2 means inch [DEFAULT]; 
3 means centimeter. 



Protocol support Optional. 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.4^8.15, Clipping Information 

Clipping Information <cllpping_informatU>n> defines a rectangular array within the item view that 
contains the pixels corresponding to the region of interest for the physical item. The clipping is comprised 
of two subelements: <clipping_origin> and <clipping_offset>. The unit of measure for the clipping 
offset are pixels. 

This compound element is to be used when the portion of the view that corresponds to the physical item 
is not equivalent to the full frame of the view (i.e. is defined by a rectangular array of pixels within the full 
view). This clipping technique differs from snippet in that the full image is presented. 



The <ciipping_offset> is a compound data subelement with subelements <h 1 >, <ti2>, <v 1 >, and <V2>. 

The clipping parameters are used to display or print the portion of the view that corresponds to the 
physical item. 

<clipplngJnfo>{02/45) ::= [ <dipping_origin> ] <us> [<cflpping_offset>] 

Protocol support Optional. 

Business Usage: Conditional, shall be present when <c!ipping_info> are conveyed.. 
6.4JL8.15.1. Clipping origin 

The Clipping Origin <clipping_origin> element conveys the comer of the full view to which the 
<clipplng_offset> data applies. Top, bottom, left, and right apply to a view which presents a visually 
correct orientation. 

Size: 01/01 
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<snippet_origln><01/01) ::= <top_right_corner_oLsnlppet> I <topJeft_corner_of_snippet> I 
<bottom_rlght_comer_of_snippet> I <bottomJeft_corner_of_snippet> 

<top_rigm_corner_of_snippct> ::= "1* 
<topJeft_comer_of_snippet> ::= °2 m 
<bottom„right_comer_of_snippet>::= °3 a 
<bottomJeft_corner_of_snlppot>::= "4 B 

Values: 1 = top right corner 

2 c top left corner 

3 = bottom right comer 

4 = bottom left comer 



Protocol support: Conditional, valid only if both snippet origin and offset are used. 
Business usage: Conditional, shall be present if necessary to identify properly the snippet.. 
6.4.2.8.14.3. Snippet off set 

The Snippet Offset <snippet_offset> element conveys the snippefs offset in both the X and Y coordinate 
direction, as related to the value of the <snippet_origin> element of protocol. The value of each 
coordinate Is expressed in terms of inches or centimeters as expressed in the Snippet Unit of 
measurement The reference edge shall be determined from the value of <snippet_origin>. The offset 
value (positive X and Y values include the center of the reference object) and shall not exceed six 
characters in length, including an embedded decimal point, when present. 

The following figure illustrates the concept In this figure the snippet area is represented by dots. 




Figure 14 - Illustration of the snippet concept 



Size: 07/27 

Type: AN (each offset is type R) 

<sntppet_offeet>{07/27) ::= <x1_offset> <usxx2_offset> <us> <y1_offset> <us> <y2_offset> 
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Business usage: Conditional, shall be present if necessary to identify properly the snippet. 
6.4.2&14.1. Snippet name 

The Snippet Name <snippeL_naihe> element conveys the functional description of the snippet view 
contained in this detail segment, i.e., the named snippet region of the item 

Size: 01/02 

Type: N 

<snippet_name>(01/Q2) ::s <courtesy_amount> I <payee_name> I <payor_name> I <mlcr_codeJine> I 
<signature> I <date_fromjtein> I <iegaLamount> I <payee_endorsement> I <bofdjendorsement> I 
<subsequent_bank_endorsement> I <subsequent_banlename> I <reserved_for_x9_snippet_use> I 
<ieservedJorjirivate.snippel.use> I <name_noLprovided> 

<name_not_provicted> ::= "0" 

<courtesy_amourrt> ::= "V 

<payee_name> ::= "2" 

<payor_name> ::= n 3° 

<micr_codeJine> ::= "4" 
<signature> "5" 

<date_from_item> ::= "6" 

<tegaLamount> ::= "7" 
<payee_cndorscroent> 
<t>ofd_en dorse ntent> 
<subsequent_bank_endorsement> 
<subsequent.banR.name> 

<feserved_for_ J x9 ,snipp e t_U8e> 

. <rcserved~tbr - j)rlvate^snippeUuse>- 

Values: 0= name not provided 
1 = courtesy amount 
2= payee name 
3= payor name 
4 = MICR code line 
5= signature 
€ = date_from Hem 
7= legal amount 

8 - payee endorsement 

9 - bof d endorsement 

10 s subsequent bank endorsement 
77 es bank name 

12 through 49= reserved for X9 use. 

50...99 = reserved for private use (as defined in the Banking Practices Agreement), and will not 
be used by X9. 

Protocol support: Conditional, valid onty if snippets are used. 

Business usage: Conditional, shall be present if necessary to identify properly the snippet... 
6.4.24.14.2. Snippet origin 

The Snippet Origin <snippet„origln> element conveys the comer of the item to which the snippet's x and 
y off-sets relate in this detail segment 

Size: 01/01 

Type: N 
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Business usage: Mandatory 
6.4.2.8.13. Orientation (of view) 

The <orientation> data element describes the orientation of the bitmap with respect to the physical item. 
The orientation data element allows users to present the bit map pixel in the proper sequence to archive 
visually a correct viewing of the displayed or printed image. 

Size: 01/01 

Type: N 

<orientation>{01/01) ::= <Jr_tb> I <r1_tb> I <r1_bt> I <lr_bt> I <tbjr> I <tb_rt> I <bt_ri> I <bt_lr> 



<drjb> "1 " - DEFAULT 

<fl_tb> ::= -2" 

<fi_bt> ::= -3 U 

<lrjrt> ::= m 4 u 

<XbJr> ::= B 5° 

<tb_H> ::= °6 a 

<bt_rt> ::= V 

<bt_lr> ::= "8° 



Values: 1 « The successive pixels constituting the first line were taken from left to right at the topmost 
edge of the imaged item. Successive lines progress from top to bottom [Default 

2 = The successive pixels constituting the first line were taken from right to left at the 
top most edge of the imaged item. Successive lines progress from top to bottom. 

3= The successive pixels constituting the first line were taken from right to left at the 
bottom-most edge of the imaged item. Successive lines progress from bottom to top. 

4 = The su ccess ive pixels constitutin g the fi rst line were t aken from left to ri ght at the 

* — I~toffom^o^efige_6fW — 

5 = The successive pixels constituting the first line were taken from top to bottom at the 

left-most edge of the imaged item. Successive lines progress from left to right. 

6 = The successive pixels constituting the first line were taken from top to bottom at the 

rightmost edge of the imaged item. Successive lines progress from right to left. 
7= The successive pixels constituting the first line were taken from bottom to top at the right- 
most edge of the imaged item. Successive lines progress from right to left. 
S = The successive pixels constituting the first line were taken from bottom to top at the 

left-most edge of the imaged item. Successive lines progress from left to right. 

Protocol support Optional 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.4J2.8.1 4. Snippet Information 

The Snippet Information <snippet_info> element conveys the identity of the region of interest for a 
specific imaged object that is associated with this data. It is composed of 4 subelements: Snippet Name, 
snippet Origin, Snipped Offset, and Snippet Unit of Measure. 

The absence shall be understood to mean full view is present The presence of this data element shall 
mean a snippet (partial view) is present. 

The term top, bottom, left, and right apply to a view which presents a visually correct orientation. 

<snlppet_lnfo>{01/31) ::= t<snippelname> ] <us> 

[<snippet_origin> <us> 
<snippet_qffset> <us> 

[<snippet_untts_of_measure>]] - ABSENCE assumed to be INCH unless stated otherwise 
Protocol support: Optional 
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6.4.2.8.10. Resolution across lines 

The Resolution Across Lines <resolution_across Jines> element specifies the number of encoded lines 
per resolution unit. 

Size: 01/08 

Type: N 

<resolution_acrossjine><01/08) ::= <numerio 
Values: 1 through 99999999 
Protocol support: Mandatory 
Business usage: Mandatory 

6.4.2.8.11. Bits per pixel 

The Bits Per Pixel <bits-per-pixel> element conveys the number of bits required to represent each 
sample associated with a pixel (indicates the number of levels captured at source). See annex B for 
specific requirements on bit ordering and padding. 

Size: 01/01 

Type: N 

<bits_per_pixet>(01/01) ::s <one> I <two> I <four> I <six> I <eight> 



<one> 

<two> 

<four> 

<slx> 

^ccight>_ 



•1" -black and white 
:= ■2" -grayscale 
:= "4" -grayscale 
to B 6" -grayscale 

:= u B m -grayscal e 



Values: 1 = Black and white; 

2 o 2 bits per pixel gray scale; 

4 =4 bits per pixel gray scale; 

6 = 6 bits per pixel gray scale; 

8 e 8 bits per pixel gray scale. 

Protocol support: Mandatory 

Business usage: Mandatory 

6.4.2.8.1 2. Interpret bitmap 

The Interpret Bitmap <lnterpret_b*rtmap> element describes how to Interpret actual values in the bitmap 
for discovering whether the minimum sample value should be understood to mean white or black. 

Size: 01/01 

Type: N 

<interpreLbitmap><01/D1) ::= <min_pbceLvaIueJs_white> I <min^bcel_valueJs_blaclo 

<min M pixeLva!ueJs_whJtB> "0" 
<mIn_pixeLvalue_is_black> ::= "1 ° 

Values: 0 minimum sample value should be output as white, and the maximum sample value should 
be output as black; 

1 minimum sample value should be output as black, and the maximum sample value should 
be output as white; 

Protocol support: Mandatory 
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6.4.2.8.7. Number of lines 

The Number of Lines <number_of_lines> data element specifies the number of encoded lines in the 
image. The relationship between pixels in these encoded lines and corresponding points on the physical 
item depends on the <orientatton> data element values. 

As an example, if the encoding is organized according to the standard viewing organization 
(<orientation>=1). the first pixel in each line would have been taken from top to bottom at the leftmost 
edge of the imaged item. 

The physical distance between successive lines is governed by the parameter 
<resolution_acrossjlnes>. 

Size: 01/08 

Type: N 

<number_of Jines>(01/08) ::= <numerio 
Values: 1 through 99999999 
Protocol support Mandatory 
Business usage: Mandatory 

6.4.2.8.8. Resolution unit 

The Resolution Unit <resolution_unit> element specifies the unit used by the elements of protocol: 
<resolution.along.line>, <resolutton_acrossJines>, and <snippet_offset>. The absence of this 
element of protocol shall be understood to mean Inch. 

Size: 01/01 

-Type:— N — 

<resolution_unft><0l/D1) ::= <none> I <inch> I <centimeter> 

<none> "1 ■ 

<inch> ::= "2" - - DEFAULT 

<centimeter> ::= "3" 

Values: 7 no unit of resolution; 

2 inch [DEFAULT]; 

3 centimeter. 



Protocol support Optional. 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.4.2.8.9. Resolution along line 

The Resolution Along Lines <resolution_alongjine> data element specifies the number of pixels per 
resolution unit along an encoded raster line. 

Size: 01/08 

Type: N 

<resotutJon_alon9Jine>{01 A>8) ::= <numerio 
Values: 1 through 99999999 
Protocol support Mandatory 
Business usage: Mandatory 
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6.4.2-8.4. View raster data size 

The Vie^v Raster Data Size <view„ra$ter_data_size> element conveys the size in bytes within 
<binary_data> component ot the BIN segment This size is 

the size of the raster data only, and does not include the size of any embedded header. 

Size: 01/10 

Type: N 

<view_raster_data_size> (01/10) ::= <numeric 
Values: 0 through 9999999999 
Protocol support: Mandatory 
Business usage: Mandatory 

6.4.2.8.5. View side indicator 

The View Side Indicator <view_slde_indicator> element conveys the type of the view contained in this 
detail segment. 

Size: 01/01 

Type: N 

<vtew_sideJndicator>(01A>1) ::= <frotrtat> I <rear> 

<frontat> ::="0 B - DEFAULT 

<rear> ::= "1° 

ValuesrO = frontal view \ D£FAULT \ y 

1 = rear view 

Protocol support: Optional 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.4.241.6. Pixels per line 

The Pixels per line <pixe!s_per_line> data element specifies the number of pixels in an encoded raster 
line. These pixels may have come from any of the possible orientation directions along the physical item, 
but constitute a "line 0 for encoding purposes. 

An example, if the encoding is organized according to the standard viewing organization 
(<orientatIon>=1 ), the successive pixels constituting the first line would have been taken from left to right 
at the topmost edge of the imaged item. 

The physical distance between successive pixels along a line is governed by the parameter 
<resolution_alongJine>. 

Size: 01/08 

Type: N 

<plxels_perjtne>(01>08) <numerlo 
Values: 1 through 99999999 
Protocol support: Mandatory 
Business usage: Mandatory 
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Business usage: Conditional , shall be present only if specified in Banking Practices Agreement 
6.4.2.8.2. View creation date 

The View Creation Date <view_creation_date> element conveys the date of the view's creation by the 
image capture equipment. 

Size: 08/08 

Type: N 

<Wew_creation_date>(0d/D8) ::= <X9_date> 
<view_raster_data_size> (01/10) ::= <numerio 

Values: YYYYMMDD where YYYY is the year, MM is the month, and DD is the day. 

VYYYis 0000 through 9999 
MM is 01 through 12 
DD is 01 through 31 

Protocol support Mandatory 

Business usage: Mandatory 

6A2.&3. View compression algorithm identifier 

The View Compression Algorithm Identifier <view_compression_algojd> element Is an identifier which 
names the compression algorithm. For additional information, see 4.1.7 and annex B. 

Five view compression algorithms have been identified for this release of the Standard in 4.1.7. It also 
provides a scheme for using other identifiers created through a national registration authority, such as 
ANSL The use of the latter scheme is subject to bilateral agreements and the disclosure of tiieschemejo 
-thereapient » — — — 



Size: 01/03 
Type: N 

<view_compresslon_algo_ld><01/03)::= <fiip_reglstered_a!gos> 

<fiip_registered_algos> <uncompressed> I <t6_facsimJle_compresslon> I <|peg_baseline> I <|blg> 

I <abio I <<reserved_for_X9> I <private> 

<urtcompressed> "1" 
<t6_facsimile_compresslon> ::= "2" 
<jpegj>aseline> ::= "3" 

<iblg> -4" 
<abio ::= "5° 

«reserved Jor_X9> "6* I I *'499 M 

<piivate> ::= "500" I -.1 "999 w 

Values: 1 = Uncompressed 

2 zs T.6 facsimile compression, 

3= JPEG Baseline (JPEG interchange format) 

4 = JBIG 

5 = ABIC 

0,6,7- 499= reserved for use by X9. 
500-999= reserved for private usage 

Protocol support: Mandatory 

Business usage: Mandatory 
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Table 47 - IVS: Item View Data segment element names 



IVS: Item View Data segment 


Size 


Data 


Ret 


Protocol 


Business 


element names 




type 




support 


usage 


<stem_view data> 







PVS1 


— 


— 


<ttem„vfaw kt> 


22/66 


AN 




o 


B1 


<view creation date> 


oa/oa 


N 





M 


M 


<view compression_a!goJd> 


01/03 


N 




M 


M 


<view_raster_data_size> 


01/10 


N 





M 


M 


<view sideJnojcatDr> 


01/D1 


N 




O 


B2 


View Decocting Information 




^ , m 











<pixet$_per_Hne> 


01/08 


N 




M 


M 


<number_of Jines> 


01/03 


N 




M 


M 


<resotutton__unit> 


01/01 


N 





O 


B2 


<resolution alona_Ene> 


01/08 


N 





M 


M 


<resc4ution_acrossJInes> 


01/08 


N 




M 


M 


<fctts oer obcel> 


01/01 


N 




M 


M 




01/01 


N 




M 


M 


<oftontation> 


01/01 


H 




O 


B2 


Partial View information 








_ . 





<snippet^tnfo> 




_ 


_ 


o 


82S 


<snlppet_name> 


01/02 


N 




C18 


B25 




01/01 


N 




C19 


B25 


<snippeUoflset> 


07/27 


AN 





C20 


B25 


<sntDoet_unJts of_measure> 


01*1 


N 


_ 


O 


B2 


<c6s30inQzinfo> 








O 


- B26 


<cflppln9_0ff^n> 


01/01 


N 


— " " 


6 


B2B 


<Eftpping n offs6fe' 


0443 


AN 


— 


O 


B26 


Additional Information 




















O 


B1 


<embeo\ted_header_lndicator> 


01/03 


N 




M 


M 


<vfew_raster_data_offset> 


01/08 


N 




M 


M 


<cr&ation_cofnpift6r> 


01/32 


AN 




O 


B1 


<vtew_<tescr1ptJon> 


01/32 


AN 




O 


B1 


<scannerjii(jji_nafne> 


01/30 


AN 




o 


B1 


<scarmer_modeI_nanie> 


01/15 


AN 




o 


B1 


<view_capture_software> 


01/30 


AN 




o 


B1 



6.4.24.1. Hem view identifier 

The Item View Identifier <ftem_viewjd> element provides a reference identifier for this segment It is 
used for storage or processing of the segment's contents. It is composed of the reference item identifier of 
the parent item loop, and a local-value. The local value is used to distinguish this view from others that 
may be associated with the imaged item. 

Size: 22/66 

Type: AN 

<item_vtewjd> (22/96) ::= <item_retjd> a "<locaLvalue> 

Values: Formed by appending a 1 to 7 digit numeric to the value of <item_refjd>. The 1 to 7 digit 
numeric shall be unique within Item Views loop structure of this transaction set See 6.4.2.5.2. 

Protocol support: Optional 
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The following table defines the Item Views structure: 



Table 46 - Item views structure element names 



Item view structure 
element names 


Size 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<item_views> 












<loop_header> 






LS 


M 


M 


<ftem_vtew_data> 






nvsi 


M 


M 


<vfaw_binary_data> 






BtN 


M 


M 


<toop_trailer> 






LE 


M 


M 



The components of the Item View structure are as follows: 

- One Loop Header <doop_header> whose syntax is defined in 6.3. 1 .5. The value of 
<JoopJd> shall be *3"; 

One item View Data <item_ view_data> segment; 

- One View Binary Data <vlewjblnaryjdata> segment whose syntax is defined in 6.3. 1. 1 1. 
The pixel values contained in the <binaryjdata> component of the BIN segment shall be 
encoded as stated in 6. 1.8; 

One Loop Trailer <loop__trailer> segment whose syntax is defined in 6.3. 1.6. The value of 
<loopJd> shall be *3". 

Item view data 

The Item View Data <item_view_data> segment conveys two classes of information associated with a 
view of an imaged item, i.e., associated with the digital representation of a single (tern. The contents of 
this se gment enables an- Fll-sy^erre^ without havin g to process 

the view's compressed raster data 

The component elements of Item View Data can be viewed as comprising the following groups of data: 

a. View preprocessing information which includes; 
Embedded non-X9 image header indicator and 

offset to the binary encoded raster data object (as illustrated in figure 13); 

b. View decoding information which includes: 
View organization information; 

Pixel description information; 

View compression information; 

View orientation information; 

Document storage and retrieval information. 

There shall be a single Item View Data segment (<item_view_data>) for each view (e.g., one for the front 
view of an imaged item, and one for the back view). Each view may be either a view of the entire side of 
imaged item, or a portion of it. The <rtem_view_data> shall indicate whether it is a full, or partial, view by 
populating appropriate elements. The syntax shall be as follows: 
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Table 47 - IVS: Item View Data segment element names 



IVS: Item View Data segment 
element names 


Size 


Data 
type 


Ret. 


Protocol 
support 


Business 
usage 


<item„vlew_data> 






nvsi 


— 


— 


<item_v1ew_id> 


22*6 


AN 




o 


B1 


<vtew_creation date> 


oa/oa 


N 


_ 


M 


M 


<vfew_oompression_alQoJ4> 


01/03 


N 




M 


M 


<view„raster_data size> 


01/10 


N 




M 


M 


<vtew_sideJnclicator> 


01/01 


N 




O 


B2 


View Decoding Information 








. 


_ 


<pixeis_perjine> 


01/08 


N 




M 


M 


<number_of JJnes> 


01/08 


N 




M 


M 


<resoiutiofi_unit> 


01/01 


N 




O 


82 


<resoiuUon_aiooq_Dne> 


01/08 


N 




M 


M 


<resolut»n_acrossJiries> 


01*8 


N 





M 


M 


<toits_per _p«et> 


01A>1 


N 


i 


M 


M 


<intefpret_bltmap> 


01/01 


N 




M 


M 


<Oftentation> 


01J01 


H 




O 


82 


Partial View Information 




„ 









<$ftippct_info> 








o 


B25 


<snippeuname> 


01/02 


N 




cie 


B25 


<sniPDet_orioin> 


01/01 


N 




C19 


B25 


^rdpp6t_,offset> 


07/27 


AN 




C20 


B25 


<snIppet n untts n of_m9asura> 


01/01 


N 





O 


82 


<cBppSnQZ,tnfo> 








o 


826 


4sSDpin(i_on(8n> 


01»1 


N 




o 


826 


«cfipping_offset» 


0443 


AN 





O 


826 


Additions! Infomuitton 












<embedded_hoBder_info> 








O 


81 


<entoeddedJroderJn(£cator> 


01«3 


N 




M 


M 


<view_raster_data_offset> 


01/08 


N 




M 


M 


<creationjoomput8r> 


0102 


AN 




O 


81 


<vtew_descrtpfon> 


01/32 


AN 




O 


B1 


<scanner_mtgr„_name> 


01/30 


AN 




o 


81 


<scanner_modeLname> 


01/15 


AN 




0 


B1 


<view_capture_jsottware> 


01/30 


AN 




o 


81 



6«4 . Item view identifier 

The Item View Identifier <item_vlewjd> element provides a reference identifier for this segment ft is 
used for storage or processing of the segments contents. It is composed of the reference item identifier of 
the parent item loop, and a local-value. The local value is used to distinguish the view from others that 
may be associated with the imaged item. 

Size: 22/66 

Type: AN 

<Hem_viewJd> (22/66) ::= <ttem_ref Jd> M . w <*ocal_value> 

Values: Formed by appending a 1 to 7 digit numeric to the value of <itenwef_id>. The 1 to 7 digit 
numeric shall be unique within Item Views loop structure of this transaction set See 6.4.2.5.2. 

Protocol support: Optional 
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The following table defines the Item Views structure: 



Table 46 - Item views structure element names 



Item view structure 
element names 


Size 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<ftem_views> 












<Joop_header> 






LS 


M 


M 


<ftem_view_data> 






pvs] 


M 


M 


<vi9w_binary_data> 






BIN 


M 


M 


<toop_trailer> 






LE 


M 


M 



The components of the Item View structure are as follows: 

One Loop Header <loop_header> whose syntax is defined in 6.3. 1.5. The value of 
<loop_id> shall be "3'; 

- One Item View Data <item_ view_data> segment; 

- One View Binary Data <view_binary_data> segment whose syntax is defined in 6.3. 1. 1 1. 
The pixel values contained in the <blnary_data> component of the BIN segment shall be 
encoded as stated in 6. 1.6; 

- One Loop Trailer <doop_trailer> segment whose syntax is defined in 6.3. 1.6. The value of 
<loopJd> shall be*3 m . 

6.4.2.8. Kern view data 

The Item View Data <ftenuview_data> segment conveys two classes of information associated with a 
view of an imaged Item, i.e., associated with the digital representation of a single Hem. The contents of 
-this segment- enables -an Fll-system-user to operate selectively on the views , withoufhavin g to process 
the view's impressed raster data 

The component elements of Item View Data can be viewed as comprising the following groups of data: 

a. View preprocessing information which includes: 

Embedded non-X9 image header indicator and 

offset to the binary encoded raster data object (as illustrated in figure 13); 
b View decoding information which includes: 

View organization information; 

Pbcel description information; 

View compression information; 

View orientation information; 

Document storage and retrieval information. 

There shall be a single Item View Data segment (<item_view_data>) for each view (e.g., one for the front 
view of an imaged item, and one for the back view). Each view may be either a view of the entire side of 
imaged item, or a portion of it The <ftem_vlew_data> shall indicate whether it is a full, or partial, view by 
populating appropriate elements. The syntax shall be as follows: 
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Table 47 - IVS: ttem View Data segment element names 



IVS: Item Vtew Data segment 
element names 


Size 


Data 
type 


Ret. 


Protocol 
support 


Business 
usage 


<uBrn_view_oata> 






EjEI 






<item^vi6wJW> 


22/GG 


AM 
AN 






B1 


<vi 8W_ciB3tion i _dat9 > 


08/08 


N 




M 


M 


<view_c<Hnpression_algo.Jd> 


01 A3 


N 




M 


M 


<view_rastGf_<lat3 — sizs> 


01/10 


H 




M 


M 


<vt8w^sia8^iriciic3tor> 


01/01 


N 




\J 


B2 














<pixete_p6f_ltn8> 


01/08 


N 




M 


M 




01/08 


u 
w 




M 


M 


<resoi uuon_uriii> 


01/01 


N 






62 


<resolLrtion„alon9_Bn©> 


01/08 


N 




in 


M 


<resolutxxvjicross_jin0s> 


01/08 


N 




M 


M 


<tMts_per_pixel> 


01/01 


N 




M 


M 


«dnterpret_bltmap> 


01/01 


N 




M 


M 


<onentaoon> 


01/01 


N 




f\ 
\J 


DO 


rbtosj view tntoftnation 












<snlppet_tnfa> 








O 


B2S 


<«nippet_name> 


01/02 


N 




C18 


B2S 


<snfpp6\_ort<jln> 


01/01 


N 




C19 


CMC 


<srtippoi w .offSG^ 


07/27 


AN 




C20 


B2S 


<snippet_units„of_m8asuTB> 


01/01 


N 




O 


82 


<cnppjnQ_uuO> - 








o 


~,B26 . .... 




01491 


N 




o 


B26 




WM 






o 


828 


Additional Information 












^embedded header info> 








o 


B1 


<embedded_headerJndlcatDT> 


01AM 


N 




M 


M 


<vfew_faster„daia„offs8t> 


01AJ8 


N 




M 


M 


<creatronjooniput6f> 


01/32 


AN 




O 


B1 


<view descftntion> 


01/32 


AN 




O 


B1 


<scanfUH , _ntfgr„n<wn©> 


01/30 


AN 




o 


B1 


<scanner„modeLname> 


01/15 


AN 




o 


B1 


<view„capture„software> 


01/30 


AN 




o 


B1 



6A24.1. Item view identifier 

The Item View Identifier <item_viewjd> element provides a reference identifier for this segment. It is 
used for storage or processing of the segment's contents, ft is composed of the reference item identifier of 
the parent item loop, and a local-value. The local value is used to distinguish this view from others that 
may be associated with the imaged item. 

Size: 22/66 

Type: AN 

<Hetn_vtewJd> (22/66) ::= <itern_refJa>". , *<locai_vatue> 

Values: Formed by appending a 1 to 7 digit numeric to the value of <ftem_ref_id>. The 1 to 7 digit 
numeric shall be unique within Item Views loop structure of this transaction set See 6.4.2.5.2. 

Protocol support: Optional 
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The following table defines the Item Views structure: 



Table 46 - Item views structure element names 



Item view structure 
element names 


Size 


Data 
type 


Ret 


Protocol 
support 


Business 
usage 


<ftem_views> 












<loop_header> 






LS 


M 


M 


<item_vtew_data> 






pvs| 


M 


M 


<vfew binary data> 






BIN 


M 


M 


<toop_trailer> 






UE 


M 


M 



The components of the Item View structure are as follows: 

- One Loop Header <loop_header> whose syntax is defined in 6.3.1.5. The value of 
<foop_id> shall be "3 

One item View Data <item^ view_data> segment; 

- One View Binary Data <view_binary_data> segment whose syntax is defined in 6.3. 1.11. 
The pixel values contained in the <binary_data> component of the BIN segment shall be 
encoded as stated in 6. 1.8; 

- One Loop Trailer <loop_traIler> segment whose syntax is defined in 6.3. 1.6. The value of 
<JoopJd> shall be *3\ 

6.4.24. Item view data 

The Item View Data <ftem„view_data> segment conveys two classes of information associated with a 
view of an imaged item, i.e„ associated with the digital representation of a single item. The contents of 
this segment-enables an Fll-system-user to operate selectivel y on the views. wrftoQt having'to process 
the view's compressed raster data. 

The component elements of Item View Data can be viewed as comprising the following groups of data: 

a. View preprocessing information which includes: 
Embedded non»X9 image header indicator and 

offset to the binary encoded raster data object (as illustrated in figure 13); 

b. View decoding information which includes: 
View organization information; 

Pixel description information; 

View compression information; 

View orientation information; 

Document storage and retrieval information. 

There shall be a single Item View Data segment (<rtem.view_data>) for each view (e.g., one for the front 
view of an imaged item, and one for the back view). Each view may be either a view of the entire side of 
imaged item, or a portion of H. The <rtem_view__data> shall indicate whether it is a full, or partial, view by 
populating appropriate elements. The syntax shall be as follows: 
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Views Structure 



OEM 
VIEW 
DATA 
SEGMENT 



BIN 
SEGUBfT 



Administrative Details 



NorvX9 tmaso 
Header indicator 




OFFSET 



Decoding Details 



Length of 
Salary data 

1 ' 1 T 

Embedded 
Header 



COMPRESSED 
RASTER DATA 



Binary data 



J 



Figure 13 -The Item Views structure model 
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Protocol support: Optional 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.4.2.5.10. User data present indicator 

The User Data Present Indicator <user_data_presentJndicator> element conveys an indication that 
supplementary information is carried in a User Data segment that immediately follows Item Information 
segment. 

Size: 01/01 

Type: N 

<user_data^>resenUndicator>(01/01) ::: <absent> I <present> 

<absent> ::= "0' - DEFAULT 

<present> ::="1" 

Values: m 0 m indicates that a User Data segmen t is not p resent [DEFAULT}, 
m 1 " indicates that a User Data segment is present. 

Protocol support Optional 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement. 
6.4.2.6. User data 

The User Data <user_data> segment conveys information that has been structured by the originating Fll- 
.^&^u^r-in-acc»rdan 

user. The content is carried in the <binary> component of a BIN segment. The semantics of the <binary> 
contents shall be understood by the receiver according to bilateral agreements specified in the 
Banking Practices Agreement 

The^syntax of the User data segment is that of a BIN segment The BIN segment syntax is specified in 

<user_data> ::= <bln_8egment> 

Protocol support: Optional 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement 



6.4.2.7. Item views structure 



Each Item Views <item_vtews> structure contains a single view of an imaged financial item (e.g. one 
digitized view of a check). It is composed of a loop header, loop trailer, a segment of item view data, and 
a binary segment containing the view's raster data. Each instance of an item view structure contains 
decoding and cross-referencing data in the <rtem_view_data> segment Each instance may contain 
decoding data in a <view_binary_data> segment that contains the compressed (or uncompressed) 
raster data. 

When performing functional decomposition, the data structure may be illustrated as in figure 13: 
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Type: N 

<item_amount>(02A12) ::= <numerio 

Values: 00 through 999999999999 
Protocol support Optional 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.4*2.5.8. Payor bank routing number 

The Payor Bank Routing Number <payor_bank_ routing_number> element conveys the routing number 
of the financial institution by, or through whom, the item is payable. If X9.37 is used, this is the Payor 
Bank Routing Number from the check detail record (type 25, field 4 and 5 concatenated). 

Size: 09/09 

Type: N 

<payor J>ank_routingjiumber>(09/D9) <routing_number> 
Values: 000000000 through 999999999 
Protocol support Optional 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.4.25.9. Image key 

The image key <imagejcey> data element contains a unique value which is assigned to the image to 
provkJe.a.CTOSSrrderence.between^ 

is unique within the ECE institution. The construction of the value is defined by <type_of_financtal_data> 
data element in the General Fll Extensions (see 6.32.7). 

Size: 34/34 

<image Jcey> (34/34) ::= <string> I 

<ece^uting_number><ece_buslTOS8_date^ 

<ece_routing_number> :va <routing _number> 

<ece_bu8tness_data> ::= <x9_date> 

<ece_sequence_number> ::= <string> 

<ece_cycte__n um be r> :i= <string> 

Values: The value shall be constructed from one or more elements contained within the associated financial 
data. 

If the financial data is in the X9.37 format, i.e., <type_of_financiaLdata> has a value of T, the 
value shall be constructed by concatenating the following X9.37 financial data elements in the listed 
order 

- ECE Routing Number (Type 20, Field 4); 

- ECE Business Date (Type 20, ReW 5); 

- ECE Sequence Number(T ype 25, Field 8); and 

- ECECycle0ype20,Field9). 

If the financial data is In any other format, i.e., <type_of_financial_data> has a value of "2" through 
"99", the value is constructed as defined by the Banking Practices Agreement of the participating 
institutions. 
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Each view associated a single imaged item may be encoded the same, or in accordance with different 
compression techniques. Six view compression algorithms have been identified for this release of the 
Standard in 4.1.7. This Standard also provides a scheme for using privately registered identifiers created 
through a national registration authority, such as ANSI. The use of the latter scheme is subject to bilateral 
agreements, and the disclosure of the scheme to the recipient. 

Size: 01/V 

Type: AN 

<compressionjndicators> ::= <view_compression_algorfthm_fd> 

{ <us> <vlew_compression_algortthmjd> } 

Values: see 6.4.2.8.3 
Protocol support: Mandatory 
Business usage: Mandatory 
6.4.2.5.4. View count 

The View Count <view_count> data element contains a physical count of the number of views conveyed 
for this imaged item. 

Size: 01/08 

Type: N 

<view_count><01/D8) ::= <numerio 

Values: 0 = 0 through 99999999 

Protocol support Mandatory 

Buslness~usa^er~Mandatory 

BAJ2JSJS. Item Information cross references 

The Item Information Cross References (<iih_cross_references>) element contains one or more 
transaction set cross references which relate this imaged item to another Item View Transaction set(s), 
Financial Data transaction set(s), or Query Request transaction set(s). There may be up to six cross 
references. 

Size: 16/257 

Type: AN 

<Hh_cross_reterences>(16/257) ::= <ts_cross_referenee> 
Values: See 6.3.2.6 
Protocol support Optional 

Business usage: Conditional, shall be present when cross referencing to another X9.46 transaction set, 
unless explicitly omitted by the Banking Practices Agreement. 

6.4.2.5.6. to be removed 

6.4.2.5.7. Hem amount 

The Item Amount <*rtem_amount> element conveys the amount (in cents) of the imaged Item. Often, the 
originator of the functional group will derive the value from the imaged item's associated ECE data. 
Minimum is 0 cents, tf X9.37 is used, this is the amount from the check detail record (type 25, field 7). 

Size: 02/12 
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Table 45 - Item Information Header Item information element names 



ll H Item information 
element names 


Size 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<tem_informatiori> 


— 


— 


PIHJ 


— 


— 


<dtem_vlewsjen&th> 


01/10 


N 




M 


M 


<jtem - ref_kl> 


20/58 


AN 




O 


81 


<oompmsstonjncficators> 


01/V 


AN 




M 


M 


<vlew„oount> 


01/03 


N 




M 


U 


^ih„cross„references> 


16/257 


AN 




O 


B23 


<ftem„ajTtount> 


02/12 


N 




O 


B2 


<payor_bank„routinfl_number> 


09X19 


N 




O 


824 


<lmage„key> 


34/34 


AN 




o 


B2 


<user„data_present_indicator> 


01/01 


N 




o 


B1 



6.4.25.1 . Item views length 

The Item Views Length (<item_vtews_length>) conveys a numeric length (in bytes) of the <rtem_vtews> 
segment's content It starts from the first byte after this segment (IIH) and includes all bytes up to (but 
excluding the start of the corresponding <loop_trafler> (LE) whose <loop_id> ="2°. 

Size: 01/10 

Type: N 

<ttem_views _length>(01 tt 0) ::= <numerio 
Values: 

Protocol support Mandatory 
Business usage: "Mandatory ~~~ 

6.4.2.5.2. Hem reference identifier 

The Item Reference Identifier <ttem_ref_ld> conveys a unique identifier assigned by the originator for the 
receiver. It is intended to be used for subsequent processing by the receiver to correlate related 
transaction sets and in acknowledgments when necessary. Its value is constructed by extending the 
<isd_refjd>. 

Size: 20/58 

Type: AN 

<ftem_refjd> (20758) ::= <Jsd.ref.id>"." <tocal_value> 

Values: Concatenation of the following data elements: 

<isd_refjd> see 6.42.32. and 
<iocal_value> which Is a 1-7 digit numeric. 

Protocol support: Optional 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement 
6.4.2-5.3. Compression indicators 

The Compression Indicators <compression_indicators> data element contains a list of all of the unique 
compression scheme identifiers used in each of the associated view detail segments for this item. Each 
unique identifier shall be separated by <us>. This may be used by the receiver to ensure that it can 
handle the compression schemes received. For additional information see 4.1 .7 and annex B. 
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6.4.2.4. Item data loop 

The Item Data Loop <item__datajoop> structure contains information about a single imaged item. 
Information (such as amount, routing number, image key, and optionally aspects of MICR code-fine data) 
is conveyed at the imaged item level while one or more digitized views, together with data needed to 
interpret the image of a check item, is conveyed within a subordinate loop. The electronic data relevant to 
the specific item is present in the <ltemJnformation> segment, while the <item_vlews> loop structure 
contains the decoding data and the compressed (or uncompressed) raster data for each view of the 
digitized Item. 

In the Fll system, the paper check, for example, is represented as a single imaged item comprising one or 
more views of the same physical item. When more than one view is present for a imaged item, one view 
may provide a frontal representation, and another view may provide a representation of the reverse side 
of the physical item. A single view shall not contain both a frontal and rear view. 

Protocol support: Mandatory 

Business usage: Mandatory 



Table 44 - hem data loop element names 



Item data loop 


Size 


Data 


Ref. 


Protocol 


Business 


element names 




type 




support 


usage 


<item_dataJoop> 












<loop_header> 






ts 


M 


M 


<signature_data> 






(SIG1 


o 


B9 


<signature> 






IBIN1 


C6 


B9 


<item„infon , nation> 






mm 


M 


M 


<user data> 






BIN 


o 


B1 


<item_yiews> 








M 


M 


<toop_trailer> 






UE 


M 


M 



The components of the item loop are as follows: 

• One Loop Header <loop_header> segment defined in 6.3. 1.5. The value of <loop_id> shall be 

• Optionally, one Signature Data <signature_data> segment whose syntax is defied in 6.3. 1. 132. 
The Length of Data <length_of _data> element refers only to the <bainary_data> component of the 
BIN segment of the <viewjbinary_data>; 

• Conditionally, one Signature Segment <signature> which conveys the digital signature whose 
syntax is defined in 6.3. 1. 13.2. This segment will be present whenever a <$lgnaturejdata> segment 
is present This digital signature is understood to apply to the <binary_data> component of the BIN 
segment of <view__binary_data>; 

• One Item Information <ftem_information> segment; 

• Optionally, one User Data <user_data> segment, whose syntax is defined in 6.42.6. A 
User Data segment is an alias for a Bin Segment. It is provided to carry a privately agreed 
stream of data; 

• One or more Item Views <Hem_vlews> segment; 

• One Loop Trailer <loop_trailer> segment defined in 6.3. 1.6. The value of <loop_ld> shall be 
6.4.2-5. Hem information 

The Item Information <Stem Jnf ormation> segment conveys Item level information. 
Protocol support Mandatory 
Business usage: Mandatory 
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Business usage: Mandatory 
6.4.2^.4.2 ISD subgroup recipient ID 

The ISD Subgroup Recipient ID <isd_subgroup_recipient_id> is a value which specifies the intended 
recipient of the image item. 

If the value of <fii_kLqualifier> is "17\ the application sender ID shall be the bank's routing number. 
Otherwise, the value of this element shall be as registered by that entity. The syntax of this element is that 
of <sender Jd> defined in 6*2-3.3.2. 

Size: 01/15 

Type: AN 

Values: See 6.2.3.3 

Protocol support Mandatory 

Business usage: Mandatory 

6.4.2.3.5. ISD cross references 

The ISD Cross References <isd_cross_referenoes> element conveys the Fll cross-referencing 
information for this subgroup of items to another Fll defined transaction set. It may be used to override or 
refine the cross-referencing value contained in the <general_RLextensions> segment The syntax is 
defined in 6.3.2.6 of this Standard. 

Size: 16/257 

Type: AN 

-r <isd^cioss^etercnoe8>(16tt57)™:»xts_crossjetew P — _ _ 

Values: 

Protocol support Optional. 

Business usage: Conditional, shall be present only if specified in Banking Practices Agreement 
6.4.23.6. ISD subgroup amount 

The ISD Subgroup Amount <isd_subgroup_amount> element conveys the calculated total amount of 
the imaged items within the Item Subgroup, tts value is conveyed in cents. 

Size: 01/16 

Type: N 

<Isd_subgroup_amounb^01/t6) ::= <numerio 
Values: 

Protocol support Optional 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 
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<isd_ief Jd><18/50) ::= <te_ref Jd>V<locaLvalue> 

<locaLvaIue>(01A>7) ::= <numerio 

Values: Concatenation of these data elements: 

Transaction set identifier (<ts_refjd>) from 6.3.2.2.; 

Local Value (<local_value>): A numeric value created by the originator such that each item 
subgroup reference identifier in this transaction set shall have a unique value. 

Protocol support Mandatory 

Business usage: Mandatory 

6.4.2.3.3. ISD item count 

The ISD Item Count <lsd Jtem_count> element conveys a total count of the items within the Item 
Subgroup structure. It is used for control purposes. 

Size: 01/08 

Type: N 

«dsd Jtem_couitt>(01 /D8) ::= <numerio 

Values: 1 through 99999999 
Protocol support Mandatory 
Business usage: Mandatory 

6.4.2.3.4. ISD Subgroup recipient 

Th^SJLSjubgipu^ 

the imaged items in this subgroup. 

For example, if the financial (ECE) data has been exchanged in X9.37 file format, this is the Final 
Destination Routing Number (Field 3) from the Bundle Header Record (Type 20) of the X9.37 file. Its 
value is not necessarily the final destination bank's routing number of each of the imaged items in the 
subgroup. 

Size: 04/18 
Type: AN 

<&d_subgroup_recipient>{04/1 8) ::= <fiijd_qualffier> <us> <isd_subgroup_reciptentJd> 

- -identifies to whom an image Hem is to be addressed. 

<isd_subgroup_recipientJd> (01/1 5) ::= <strlng> 
Protocol support Mandatory 
Business usage: Mandatory 
6.4*2^.4.1. FIND qualifier 

The Fll ID Qualifier <fiij<i_qualifier> element conveys a value indicating the registrar of the 
Fll Acknowledgment Recipient ID information. The syntax of this element is that of <interjd_qualifef> 
defined in 6.2.3.3.1. 

Syntax and values are specified in 6.2.3.3.1 
Protocol support Mandatory 
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• One Item Subgroup Information <Hem_subgroupJnformation> segment; 

• One or more Item Data Loop <ftem_data_loop> structures. Each instance of the 
<item_d3ta_loop> is relevant to a single item.; 

• One Loop Trailer <loop_traUer> segment whose syntax is defined in 6.3. 7.6. The value of 
<foop_id> shall fce V. 



6.4.Z3. Item subgroup information segment 

Each Item Subgroup Information segment (<item_subgroupJnformation>) conveys supporting 
information which is relevant to all items of the imaged Item Subgroup, tt is carried for control and routing 
purposes. Its values apply to all imaged item data structures contained within the bounding Loop Header 
(LS(1 )] and corresponding Loop Trailer. 

Protocol support: Mandatory 
Business usage: Mandatory 

Table 43 - ISD: Item subgroup Information element names 



ISO: Item subgroup tnformatton 
elements names 


Size 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<ften\_pubgroupJnformatibn> 






PSD] 






dtem_data H loop tength> 


02/10 


N 




M 


M 


<ted_refjd> 


1860 


AN 




M 


M 


<isd_ft0nr> oount> 


01/08 


N 




M 


M 


4sd_subgfoup^.recfpl6nfc 


04/18 


AN 




M 


M 


4sd M cross_reference9> 


16/257 


AN 




o 


* * B1 


<isd subQfOup_.8mounfr 


01/16 


N 




o 


B2 



6AZ3.1 . Item data loop length 

The Item Data Loop Length <item_dataJoopJength> element conveys the total size (in bytes) of the 
<hem_dataJoop> structure, tt starts from the first byte after this segment (ISD) and includes all bytes up 
to (but excluding) the start of the corresponding <loop_trailer> (LE), whose <toop Jd>= a 1 a .. 

Size: 02/10 

Type: N 

<ftem_data_k>op_tength>{02fl 0) <numerio 

Values: 1 through 9999999999 

Protocol support Mandatory 

Business usage: Mandatory 

6.4.2&2L Item subgroup reference identifier 

The Item Subgroup Reference Identifier <isd_ref_W> element conveys a unique identifier assigned by 
the originator. It may be used by a receiving Fll-systenvuser for acknowledgments, or audit and control 
purposes. 

It is constructed by concatenating the value of <ts.ref.id>, and a locally determined 1-7 digit numeric 
value. This value shall be unique to this transaction set The local value is separated from the rest of the 
identifier by a V character in order to avoid any possibility of ambiguity. 

Size: 18/50 

Type: AN 
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6.4.2.1. Item group transaction set 

Each Item Group Transaction Set <item_group_ts> specifies a group of imaged items which have been 
grouped together for the purposes of the interchange; they may or may not share a common bond. For 
example, in the context of the forward or return processing of paper checks, the set may be thought of as a 
cash letter. 

Protocol support Mandatory 
Business usage: Mandatory 



Table 41 - Item group transaction set element names 



Item group transaction set 
element names 


Stoo 


Data 
type 


Rol. 


Protocol 
support 


Business 

usage 


<item_groupjts> 












<trans_sei_header> 






ST 


M 


M 


<general_F! l_extensions> 






JS2L 


M 


M 


<item_subqroup> 








M 


M 


<tfans_set_trailer> 






SE 


M 


M 



Each transaction set comprises the following segments: 

• One Transaction Set Header <trans__set^header> segment 

Its syntax is defined in 6.3. 1.3. The value of <trans_seUd> shall be TTS •; 

• One General Fit Extensions <general_FILextensions> segment whose syntax is defined 
in 6.3.2; 

• — One or more Item Subgroup(s)<item-subgroup> structures;- 

• One Transaction Set Trailer <trans_set_tralter> segment, whose syntax is defined in 
6.3.1.4. 

SAJ2J2L Item subgroup 

An Item Subgroup <ftem_subgroup> specifies a subgroup of imaged items. 

In the paper item world of forward processing, a subgroup could correspond to a bundle of checks. 

Protocol support Mandatory 

Business usage: Mandatory 



Table 42- Item subgroup loop structure element names 



Item subgroup loop structure 
element names 


Size 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<ttem^svbgroup> 












<k>op_header> 






LS 


M 


M 


<ftem_subgrouD information* 






PSO|, 


M 


M 


4tam_dataJooi» 








M 


M 


<toop_traiJer> 






IE 


M 


M 



The components of each instance of an Item Subgroup loop are as follows: 

• One Loop Header <loop_header> segment, whose syntax is defined in 6.3. 1.5. The value of 
<loop_id> shall be V; 



83 



COPYXIQHT American national Standards Institute 
Licensed by Information Handling Services 



Best Available Copy 



XP008074623 



X9.46-1997 

h For example, if the value of <type_ol_financlal_data> is '1", it indicates that the content ol the 
<binary_data> element contains a financial data stream whose encoding conforms to the requirements 
of X9.37. 

<financial_data> <bin„segment> 
Protocol support: Mandatory 
Business usage: Mandatory 
6.4.2. ttem views functional group 

The Item Views Functional Group <rtem_viewsjg> is used by the Fll-system-user to convey groups of 
Item imaging information or views, or both. Included in each group are one or more transaction sets of 
item imaging information or images, or both. Included in each transaction set is one or more loops 
containing subgroups of item imaging information and corresponding views of an imaged item. 



Table 40 - Item views functional group element names 



Item views functional group 
element names 


Size 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<dtem_vtews_fg> 












<fgjteader> 






GS 


M 


M 


<fg_securfty_header> 






S1S 


0 


B9 


<skjnatur& ts> 








0 


B9 


<tt6tn_grottp ts> 








M 


M 


<fg_securfty__traiier> 






S1E 


C1 


B9 


<ffl_trailer> 






GE 


M 


M 





Each Item Views functional group comprises the following: 

• One Function Group Header <fgjheader> segment; 

The Functional Group Header <fg_header> syntax is defined in 6.3. 1. 1. The value of 
<functional _groupJd> shall be 7 V for an Item Views functional group; 

• Optionally, one Function Group Security Header segment; 

The Functional Group Security Header <fg_security_header> segment syntax is defined in 
6.3.1.7; 

• Optionally, one Signature Transaction Set structure; 

The Signature Transaction Set structure <signature_ts> syntax is defined in 6.3. 1. 13. 1; 

• One or more Item Group Transaction Sets <item_groupJts> structured); 

• Conditionally, one Function Group Security Trailer segment, 

The Function Group Security Trailer <fg_securityjtrailer> segment syntax is defined in 6.3. 1.6; 

• One Functional Group Trailer segment <fg_trai!er> segment; 

The Functional Group Trailer segment <tgjraiter> syntax is defined in 63. 12. 
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Views functional Group for the purpose of cross referencing and tracking, or other local 
purposes. The Financial Data transaction set is defined in 6.4. 1.1 of this Standard; 

• Conditionally, one Functional Group Security Trailer segment; 

The Functional Group Security Trailer <fg_secur'rty_ trailer> may provide the MAC for data 
integrity purposes, and shall be present when the <fg_security_header> data element is 
present to signal the end of the security mechanism identified in the <fgjsecurityjheader>. The 
syntax shall be as specified in 6.3.1.8; 

♦ One Functional Group Trailer segment; 

The Functional Group Trailer <fgjtrailer> designates the end of a functional group. It is defined 
in 6.3.12. 

6 A 1.1 Financial data transaction set 

Each Financial Data Transaction Set <financiaLdata_t_set> conveys the segments that are used to 
exchange financial data. There shall be a single instance of a financial data segment per Financial Data 
Transaction Set This financial data may relate to one, or more, image sets being exchanged between the 
financial institution applications. There may, or may not, be a relationship between the financial data in an 
interchange and an item view's functional group in the same interchange. 

Protocol support Mandatory 

Business usage: Mandatory 

The structure of a financial data transaction set shall be as follows: 



Table 39 - Financial data transaction set element names 



Financial data transaction set 


Stee 


Data 


Ret 


Protocol 


Business,. 


element names 




type 




support 


usage 


<finandaLdata_t_set> 












<trans_set_header> 






ST 


M 


M 


<general_.FILextenstons> 






IGFD1 


M 


M 


<financia1_data> 






BIN 


M 


M 


<trans_sectrailer> 






SE 


M 


M 



Each Financial Data Transaction Set <financiaL.dataLt.set> comprises the following segments: 

• One Transaction Set Header <trans_set_header> segment. 

Its syntax is defined in 6.3. 1.3. The value of <trans_seLid> component shall be "FTS"; 

• One General Fil Extensions <generaLFILextenslons> segment 

Its syntax Is defined in 6.32. The elements <type_of_financial_data> and <type_of__ts_data> 
shall have values unless a DEFAULT value is appropriate; 

• One Financial Data <financial_data> segment 

It may only be absent when the interchange is a test Fll; 

• One Transaction Set Trailer <trans^sel_traller> segment, whose syntax is defined in 6.3. 1.4. 
6.4.1.2 Financial data segment 

The Financial Data Segment <financial_data> is used in this transaction set to carry financial data as a 
continuous stream of data in a binaiy segment <bin_segment>. The <bin_segment> carries a 
<binary_data> element. The encoding and semantics of the <blnary_data> element shall be as 
specified in the <type_of_financial_data> component of <generaLRLextensions> defined in 6.3.2.7. 
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Protocol support: Conditional, valid only in a hem Group Transaction Set . 

Business usage: Conditional, shall be present only in an Item Group Transaction Set.. 

&4 Functional groups definitions 

The following clauses define the X9 defined functional group structures used in the protocol, introduced in 
6.2.1, and illustrated in annex F. 

6-4.1 Financial data functional group 

The Financial Data Functional Group <f inancial_data Jg> is the functional group that conveys financial 
data, such as an electronic cash letter. When present, the contents may relate to an Item Views functional 
group In this, or another, interchange. Depending upon the local security policy in force, mechanisms may 
need to be present for FN authentication, and non-repudiation security services. 

Because of the importance of the financial data, it is recommended that financial data functional groups 
be sent in separate interchanges. 

The data structure shall be defined as follows: 



Table 38 - Financial data functional group structure element names 



Financial Data functional group 
structure element names 


Size 


Data 
type 


Ret 


Protocol 
support 


Business 
usage 


<flnandal v dateUg> 












_ - <fg_headei> 






— OS — 


M- - 


M 


<fg_securtty_heaoer> 






S1S 


o 


89 


<si<jnatuf 1 6_ts> 








o 


B9 


<finandal_dat£LJ_&6t> 








M 


M 


<fg M securfty_tmfter> 






S1E 


C1 


B9 


<fp__traitef> 






GE 


M 


M 



Each Financial Data functional group <financiaLdataJg> structure comprises the following segments: 

• One Functional Group Header segment 

The Functional Group Header <fg__header> identifies a financial transaction. Its syntax is 
defined in 6.3. 1. 1. The value of <functlona! _groupJd> shall be 70°; 

• Optionally, one Functional Group Security segment 

The Functional Group Security <fg_securfty__header> may be used to provide data integrity and 
data protection to the entire functional group's contents. It also may convey the algorithm 
Identifier used in the signature transaction set that may follow. The syntax shall be as specified 
in 6.3.1.7; 

• Optionally, one Signature Transaction Set structure. 

The Signature Transaction Set <signature^ts> may be used to provide authentication checking 
by the receiver. The algorithm used to create the digital signature is found in the associated data 
segment The syntax shall be as specified in 6.3. 1. 13. 1; 

• One or more Financial Data Transaction Set structure^). 

Each Financial Data Transaction Set <financial_data_t_set> contains a single financial data 
stream and preprocessing information, its stream of financial data is carried as a binary object 
whose syntax and semantics is specified by the sender. For example, the user may send the 
data in the binary object in the format specified by X9.37. It may be associated with an Item 
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Business usage: Conditional, shall be present when <generalJiLextensions> are conveyed in the 
Item Group Transaction Set. 

6.3.2.10. Item group amount 

The Item Group Amount <item__group_amount> element conveys the total value of the items contained 
in the Item Group Transaction Set conveyed in cents. If X9.37 is used and all of the items in the cash 
letter have an image in this group, this is the Cash Letter Total from the Cash Letter Trailer record (type 
90, field 4). 

Size: 01/16 

Type: N 

<hem_group_amount><01/1 6) ::= <numerio 
Values: Locally determined 

Protocol support: Conditional, valid only in a Item Group Transaction Set 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

6.3.2.11. Hem group recipient identifier 

The Item Group Recipient Identifier <item_group_reciptent_id> element conveys the value as it is 
provided by the originating financial institution. Its value identifies the intended destination of all imaged 
items in the transaction set. 

When the group relates to a digital cash letter conveyed in a X9.37 compliant format, the value shall be 
that of the Final Destination Routing Number from the Cash Letter Header record (type 10, field 3). 

The syntax of this element is the same as <send_acknow1edgments_to> defined in 

6.3.2.5 of this specification. 

Size: 04/18 
Type: AN 

<item jroup_redpienUd><04rt 8) ::= <send_acknowtedgmentsJo> 
Value: see 6.2.3.3.2 

Protocol support: Conditional, valid only in a Item Group Transaction Set . 

Business usage: Conditional, shall be present only in an Item Group Transaction Set.. 

6.3.2.12. Item subgroup count 

The Item Subgroup Count <item_subgroup_count> element conveys a value which is the total number 
of item subgroups in the transaction set. If the subgroup represents images of an X9.37 bundle, this value 
is the number of bundles. 

This data element is only used when <generaLFII_extensions> are conveyed in the Item Views 
functional group. 

Size: 01/08 

Type: N 

<Hem_8ubgroup_count>(01A>8) ::= <numerio 
Values: 0 through 99999999 
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<type_of JinOTCiaLdata>(01/02) ::= <x9_37> I <eccho> t <federaLre$erve_cips_format> 
I <reserved_for_jtfLuse> I <private_formats> 



<X9_37> 
<eccho> 

<tederal_reserve_cips_fo rmat> 

<reserved_for_x9_use> 

<private_formats> 



:=M" -DEFAULT 
is "2" 
:= w 3* 

:= "4" I - I "50" 

:= -sri ... re- 



values: 1 X9.37 conformant processing data [DEFAULT]; 

2 ECCHO conformant processing data; 

3 Federal Reserve CIPS-format; 
4..50 Reserved for X9 use; 

51 ..99 Reserved for private use by financial institutions 



Protocol support Optional. 

Business usage: Conditional, shall be present unless explicitly omitted in the Banking Practices 
Agreement 

£3.2.8. Count of financial data items 



The Count Of Financial Data Items <count_of_financial_dataJtems> element conveys a value which is 
a total count of the items contained in the financial data's BIN segment This data element is used only 
when <generaLFll_extensions> are conveyed in the Financial Data Transaction Set 

For example, if the ECE data is in X9.37 format, this shall be the value of the Items field within Cash 
Letter Count (Field 3) from Cash Letter Control Record (Type 90) of the X9.37 data stream. 

Size: 01/08 
Type: N 

<count_of_financiaLdataJtem3>(01A)8) <numerio 
Values: 0 through 99999999 

Protocol support Conditional, valid only in a Financial Data Functional Group. 

Business usage: Conditional, shall be present when <generaLfiLextensions> are conveyed in the 
Financial Data Functional Group.. 

6.3.2.9. Count of imaged Hems 



The Count Of Imaged Items <count_ofJmaged_items> element conveys the originator's count of the 
imaged items contained In this transaction set This element is used only when 
<generaLFILextensions> are conveyed in the Item Group Transaction Set This is not a count of the 
number of views. 



Size: 01/08 
Type: N 

<count_of_jmagedjtem3>{01/08) ::= <numerio 
Values: 0 through 99999999 

Protocol support: Conditional, valid only in a Item Group Transaction Set 
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6.3.2.5.1. HI ID qualifier 

The Fll ID Qualifier <fii_id_qualifier> element conveys a value indicating the registrar of the 
Fll Acknowledgment Recipient ID information. The syntax of this element is that of <interjd_qualifier> 
defined in 6.2.3.3.1. 

Values: see 6.2.3.3.1 

<interjd_qualffier> (02/02) ::= <ld> - data element 105 : X12.5 

Protocol support Mandatory 

Business usage: Mandatory 

63.2.5.2 Fll acknowledgment recipient ID 

The Fll Acknowledgment Recipient ID <fii_ack_jecipien1Jd> is a value which defines the intended 
acknowledgment recipient 

If the value of <fiijd_qualifier> is "17", the application sender ID shall be the bank's routing number. 
Otherwise, the value of this element shall be as registered by that entity. The syntax of this element is that 
of <senderjd> defined in 6.2.3.3.2. 

Values: See 6.2.3.3 

Protocol support: Mandatory 

Business usage: Mandatory 

63.2.6. Transaction set cross references 

The Transaction Set Cross References <ts_eross_references> element conveys a sequence of one, or 
more transaction set cross references to which this transaction set relates.. For_example t .thistypeof.cross- 
reference can be useful for cross-referencing outstanding query requests to responses, or item view(s) to 
financial data transmissions which were sent in earlier transmissions. 

The subelement separator <us> shall be present when more than one value is present 

Size: 1 6/257 (up to 6 instances of <ts_ref_id>) 
Type: AN 

<ts_cross_references>(1 6/257) <ts_refj<f> { <us> <ts_refjd> } - maybe repeated up to six times 
Values: concatenation of the transaction set cross reference elements 
Protocol support Optional 

Business usage: Conditional, shall be present when responding to query request, may be present for 
other transaction sets.. 

63.2.7. Type of financial data 

The Type Of Financial Data <type_of_financiaLdata> element conveys an indicator of the layout of the 
financial data contained In the binary data segment for this Financial Data Transaction Set 

Size: 01/02 

Type: N 
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Business usage: Conditional, shall be present If an acknowledgement is requested, and the defaults are 
inappropriate.. 

63.2.4.3 Acknowledgment Security 

Acknowledgment Security specifies what, if any, security services are requested with the requested 
acknowledgment 

Size: 01/02 

Type: N 

<ack_securtty> <no_secj3_requested> I I <non_repudiation_sec_ls_requested> I <macd 
_secjs_requested> I <data_prx>tected _secjs_requested> I 

<non_repud_and_data_j>rotected_sec Js_requested> I <non_repud_and _macd_sec_te_requested I 
<macd_and_data_protected_sec is_requested> I <macd_data_protected_and non_repud_secJsjreq> 

<no_sec_ls_requested ::= "0" 

<non_repudiatlon_sec_ls_requested>::= "1" 
<macd_sec_is_requested> "2" 
<datajm>tected_sec n ls_requested>:.*= "3" 
<non_iepudjan(Ldata 1 _jTOtected.sec.ls„iequested>:^ "4" 
<non_repud_and _macd_sec_is_requested>::= M 5** 
<macd_and_data^rotected_secjs_requested>::= "6" 
<macd_data _protected_and non_repud_secj9_req>::= T* 

Values: 0= No security requested; [DEFAULT] 

1o Non-Repudiation security is requested; 

2= Matfd security is requested 
_ 3= Data Protected security is requested; 

4= Non-Repudiation and Data Protected security is requested 

5= Non-Repudiation and Matfd security is requested 

6= Matfd and Data Protected security is requested; 

7= Mac'd.Data Protected, and Non-Repudiation security is requested. 



Protocol Support Optional 

Business Usage: Conditional, shall be present if an acknowledgement Is requested, and the defaults 
are inappropriate. 

6.3.2-5. Send acknowledgments to 

The Send Acknowledgments To <send_acknowtedgments_to> element names the originatinator's 
desired recipient to which to direct Fll acknowledgment. The absence of this element of protocol conveys 
the semantics that acknowledgments are to be returned to the value of ISA Header's component 
Sender (<sender>). When present, it comprises two data elements: <fiU<Lqualffier> and 
<nLacK-.recipient.ici>- See 6.2.3.3.1. 

<send_acknow!edgments_to>(04/1 B)::= <filjd_qualtfier> <us> <fiLack_recipIentJd> 

— Identifies to whom a Fll acknowledgments is to be addressed if other than the originator 

<fiUd_qualifier> (02/02) ::= <interjd_qualffier> 
<fu_ack_reciptentLtd> (01/15) ::= <string> 

Protocol support Optional 

Business usage: Conditional, shall be present only to redirect an acknowledgement to a recipient other 
than the sender of this functional group.. 
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Business usage: Conditional, shall be present if an acknowledgement is requested, and the defaults are 
inappropriate.. 

6.3.2,4.1 Acknowledgment condition 

The Acknowledgment Condition (<ack_condition>) subelement specifies the conditions under which an 
acknowledgment should be generated by the receiver of the interchange, i.e.. if it accepts the interchange 
or fails to accept the interchange, or both, or neither. When the General Fll Extensions segment is used in 
the context of a Query Request the Acknowledgment Condition shad be other than 0. 

Size: 01/01 

Type: N 

<ack_condition><01/01) ::= <ack_not_requested> I <ack ta _on_failure_or_success> 

I <ack_only_on_fai)ure> I <acR_only_on_success> 



<ack_not_reque$ted> 
<ack_on_failure_or_success> 
<ack_only_on_failure> 
<ack_only_on_success> 



:= "0"- - Overides any value if present in <type_of_request> 

IS "1" 

» "2"- DEFAULT 
» "3" 



Values: 0= Acknowledgment not requested; 

1 = Acknowledgment requested on failure or success; 

2s Acknowledgment requested only on failure, i.e., rejection of the interchange or its 

component. [DEFAULT]; 
3= Acknowledgment requested only on success i.e., acceptance of the interchange 

or its component. 

Protocol support Optional. 

-Business usage: — Conditional r shall be present if an acknowledgement is requestedrand the defaults are ~ 
inappropriate.. 

6.3.2.4.2 Type of request 

The Type Of Request (<type_of jnequest>) subelement specifies the type of acknowledgment response 
requested. 

tf the Acknowledgment Condition is 0, both the preceding subelement delimiter and a value in the Type 
of Request subelement shall be absent. 

Size: 01/02 
Type: N 

<type_ot_request>(01A>2) ::= <func_ackjs_requested> I <app_ack_is_requested> I 

<both_fa_and_aa_are_requested> 

<func_ackjs_reques*ed> ::= "0" 
<app_ackJs_requested> ::o -1 " - DEFAULT 
<both_fa_and_aa_are_requested> ::= "2 W 

Values; 0= Functional Acknowledgment is requested; 

1 = Application Acknowledgment is requested [DEFAULT]; 

2= Both a Functional Acknowledgment and an Application Acknowledgment are requested; 
Protocol support: Optional 
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<type_ofjs_data><01/03) ::= <response_to_queiry> I 

<forwartLprocesslng> I <retums>l <positive_pay> l<account_recon>J <subpoena> l<signature.verffy> I 
<statementing> I <mlxed__type> I <ie&erved_for_x9> I <private_ts_type> 

<response_to_queiy> ::= '1° 

<fofward_proccssing> ::= "2" 

<retums> ::= - 3" 

<pasffive_pay> ::="4 a 

<account_recon> i^S" 

<subpoenao :r="6 a 

<slgnature_vertfy> :x*7" 

<stafementing> :x"8" 
<mlxed_type> "9" 

<teserved Jor.jc9> ::= "10*i r500 n 

<prlvate_ts_type> ::= "501 "I ~ l n 999" 

Values: 

1 Response to query 

2 Forward processing 

3 Returns 

4 Positive Pay 

5 Account reconciliation 

6 Subpoena 

7 Signature verify 

8 Statemenling 

9 Mixed Types 

10 ...500 - reserved for X9 

501 ...999 - reserved for privately agreed usage 



Protocol support Conditional, Conditional, valid only when the value of <trans_setjd> in the Transaction 
Set header is Item Group, Financial Data, or Query Request 

Business usage: Conditional, shall be present for transaction sets containing item group, financial data, 
or query requests.. 

6*3.2.4. Recipient acknowledgment request 

The Recipient Acknowledgment Request <reciplent_ack u _request> element conveys the application 
sender's request for a specific kind of acknowledgment for this transaction set It specifies: 

1 . Under what conditions, if any, acknowledgments are to be generated, 

2. Whether a Functional Acknowledgment, an Application Acknowledgment, or both is to be sent, 
and 

3. The type of security to be applied to any requested Application Acknowledgment. 

It is composed of three subelements: The acknowledgment condition (<ack_condition>) and the type of 
acknowledgement requested (<type_of_request>) and <ack_security>. The acknowledgment condition 
(<ack_condition>) subelement conveys the condition. The type of acknowledgement requested 
(<type_of„request>) subelement conveys both the type and kind of security mechanism to be applied to 
Application Acknowledgments, and the <ack_security> specifies the security services that are requested 
with the acknowledgment 

The absence of this data element conveys the semantics that unsecured Application Acknowledgment is 
to be generated only on failure. 

<reclptent _ack_request>(01/04) — [<ack_condition> ] <us>{<type_of_request>] <us> [<ack_security>] 

Protocol support: Optional. 
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6.3.2.1. TS length 

The Transaction Set Length <ts Jength> element conveys the total length (in bytes) of the transaction 
set's contents. It starts from the first byte after this segment, and includes all bytes up to (but excluding) 
the start of the corresponding <trans_set_trailer> (SE). It may be used by a recipient to determine the 
end of this transaction set. 

Size: 02/15 

Type: N 

<ts_length>(02/l 5) ::=<numerio 

Values: locally calculated 

Protocol support Mandatory 

Business usage: Mandatory 

6.3.2JL Transaction set reference identifier 

The Transaction Set Reference Identifier <ts_ref_id> element conveys a globally unique identifier that is 
used by Fll-translators and Fll-system-users for cross-reference purposes. It is formed by concatenating 
aspects of the Functional Group Header and the Transaction Set Header. The date and time components 
are expressed in terms of originating Fit-translator's local information. The date component is the 
originator's business date, which may be different from the actual processing date. 

Size: 16/42 

Type: AN 

<ts_ref Jd>(1 6/42) - provided for cross-referencin g pur poses 

<appJBende^Jd> , ^' , 
<funetion_controLnumber>". t ' 
<trans_set_control_nu mber> 

Values: Concatenation of these data elements: 

- Functional Group Date from FG header, whose syntax and semantics are defined in 6.3. 1. 1.4; 

- Application Sender ID from FG header, whose syntax and semantics are defined in 6.3. 1. 1. 1; 

- Functional Group Control Number, whose syntax and semantics are defined in 6.3. 1. 1.6; 

- Transaction Set Control Number from TS header, whose syntax and semantics are defined in 

6.3.1.3.2. 

Protocol support Mandatory 
Business usage: Mandatory 
6.3.23. Type of transaction set data 

The value of Type Of Transaction Set Data <type_of_ts_data> element indicates the originating Fll- 
system-user's reason for sending the transaction set. 

When the value Indicates that the contents of the transaction set is in response to a Query Request, the 
<ts_cross_references> shad contain the <ts_refjd> of the subject query request. 

Size: 01/03 

Type: N 
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Table 36 - General Fll extensions: element assignment to transaction sets 



General Fll Extensions: 


Financial 


Item 


Application 


Query 


element assignment 


Data 


Group 


Acknowl- 


Requests 


to transaction sets 


TS 


TS 


edgment TS 


TS 


<general_RLextenslons> 












^i£> — iciiy 


v 

T 


y 


Y 


Y 


rat IrW 


V 
T 


Y 


Y 


Y 




T 


v 

T 


Y 


Y 




v 

T 


Y 


Y 


Y 


Cacvv^cui tuiuons> 


Y 


v 

T 


v 

T 


Y 




v 
T 


v 

T 


Y 


Y 


<sand scknowkiHomfints to> 


y 


Y 




Y 


<fii_id_qua!ifier> 


Y 


Y 




Y 


<fij_ack_recipienl_ld> 


Y 


Y 




Y 


<tS„CfOSS_rGf6f6nOBS> 


Y 


Y 


Y 


Y 


<type_ofJinanciaLdata> 


Y 








<courtLof„financial_dataJtems> 


Y 








<count_of„lmaged_ftents> 




Y 






<item_flroup_amount> 




Y 






dtBfn_group_r©cipi8nt^ltl> 




Y 






<it8m_subgroup_count> 




Y 







Y- indicates the applicability of the element 



The following table defines the elements contained in the General Fll Extensions segment 



Table 37 • GFD: General Fll Extensions element names 



GFD: General Fll extensions 
element namess 


Size 


Data 
type 


Ret. 


Protocol 
support 


Business 
usage 


<gen8raLFtl_extensions> 






[GFD] 






<ts_Jenpth> 


02/15 


N 




M 


M 


<ts_ref_W> 


16/42 


AN 




M 


M 


<type_of,js w data> 


OlAtt 


N 




CS4 


B14 


<redpient _ack_reauest> 


01/04 






O 


B12 


<ack_conditions> 


01/01 


N 




O 


B12 


<type_of_request> 


01/02 


N 




O 


B12 


<ack^securtty> 


01/02 


N 




O 


B12 


<send_acknowtBdgments_to> 


04/18 






o 


B15 


<fnjd_quafifier> 


02/02 


10 


105 


M 


M 


<€l_adc_redpient.W> 


01/15 


AN 


106 


M 


M 


<ts_cross_references> 


16/257 


AN 




O 


B13 


<type„of„financtaIjdata> 


01/02 


N 




o 


B2 


<counUof_financtai_dataJtams> 


01/08 


hi 




C9 


B18 


<coum_oJJmaqed_tems> 


01/08 


N 




C10 


B19 


<Jtem_^roup_amount> 


01/16 


N 




C10 


B2 


<item_group r .rec]pient_U> 


04/18 


AN 




C10 


B20 


<ftem_8ubgtoup_count> 


01/08 


N 




C10 


B21 



The General Fll Extensions segment <generaLFILextensions> is composed of a collection of elements. 
The usage of a specific element differs among transaction set types as indicated in table 30. The 
following clauses specify the syntax and usage of the elements that comprise this segment: 
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User registered algorithms: defined as <identifier_string>{<usxidentcfier_string>} 
Protocol support: Mandatory . 
Business usage: Mandatory . 
6.3.1. 13.22. Algorithm length of key and block size 

When present, the <key_and_or_block_size> conveys the length of the encypherment algorithm's key 
and/or block size used to create the digital signature. Its presence depends upon the encypherment 
algorithm used. 

Size: 01/06 

Type: N 

<key_arKLor_blocK_size>(01/D6) ::=<numerio 

Values: determined by the signature encryption algorithm (symmetric key encypherment algorithm). 
Protocol support Conditional, valid only If required by or applicable to the security mechanism utilized.. 
Business usage: Conditional, shall be present only If the algorithm used to encipher the data requires it 
6-3.1.13^.3. Length of data 

The Length of Data <length_of_data> element identifies the number of bytes being protected, starting 
from the first byte of the <signature> segment, including all bytes up to, but excluding, the start of the 

j©gmentMlQV\ri 

6.3.2. General HI extensions 

General Fll Extension <general_FILextensions> is a set of elements unique to the Rl usage of a 
transaction set It supplements the X12 defined Transaction Set Header to the extent that its values apply 
to the contents of the entire transaction set The following table indicates the applicability of each General 
Fll Extensions element by transaction set type. 
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• One Transaction Set Header <ts_header>, whose syntax is defined in 6.3. 1.3. The value of the 
component element <trans_seUd> shall be m STS m ; 

• One Signature Data Segment <signaturejdata> 9 whose syntax is defined in 6.3. 1. 13£; 

• One Signature Segment <signature>, which conveys the digital Signature whose syntax is 
defined in 6.3.1.11; 

• One Transaction Set Trailer <tejtrailer> t whose syntax is defined in 6.3. 1.4. 
S3 A A 3.2. Signature data segment 

The Signature Data Segment <signature_data> conveys sufficient information to verify the digital 
signature's authenticity, i.e., that it was created by the originating financial institution. 



Table 35 - SIG: signature data element names 



SIG: Signature Data 
element names 


Stoe 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<slgnaturejttata> 






ISIG] 






<securfty„offg_name> 


04/16 


AN 


824 


M 


M 


<securfty_rectp_name> 


04/16 


AN 


825 


M 


M 


<authenLalgorithm_id> 


01/15 


AN 




M 


M 


<key_and_or_Wock_stee> 


01/01 


N 




C11 


B11 


<i en{jfth_cf _data> 


01/18 


N 


995 


o 


B11 



The following elements are defined in 6.3.1 .7: 

- <security_orig_name>; 

- <security_reclp_name>. 

The following definition pertain to the elements not defined in other parts of this standard: 
6.3.1.13.2/1. Authentication algorithm identifiers 

When present, the <authent_a1gorithm_id> conveys the identifier of the enciphering algorithm used to 
create the digital signature. 

Note: The set of cryptographic algorithms identified in this standard agree with X9*s Cryptographic Policy 
Standard. March 10, 1994 which is on record wOh the X9 secretariat 

The use of enciphering schemes may be subject to copyright protection, or patent infringement laws, or 
legislation. The inclusion of these identifiers in no way constitutes a requirement for their use. Thus, 
besides registering several data security algorithms commonly used in the US, a general purpose 
mechanism is also provided for naming the algorithm used between institutions, but not expressly 
registered herein. 

Size: 01/15 
Type: AN 

<authent_atgorittimJd> (01/15) ::=<rsaJso9796> I <dsa> I <identffief_string>{<identifier_string>> 

<rsa w lso9796> ::= <rsa_with_md5 1 <rsa_wlth_sha-1 > I <fsa.wftti.mdc2> 

- - from \SOAEC 9796 
<jsa_with_md5> °43.1 4*3.2£3 a 
<fsa_wttti_Bha-1> ::= "43.14^.2-29" 
<Tsa_with_mdc2> ::= "43.14.3.2.14" 

<dsa>::= <dsa_wtth-sha-1 > 
<d3a_wtth-sha-1> °43.14^27* 
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• <no_ofJnduded_sets> as defined in X12.22 as AK9Q2, an alias for data dement # 97; its 
value is the value of the <noJnclude_sets> (as defined in 6.3. 1.2. 1) found in the <fgjtrailer> 
of the subject functional group being acknowedged; 

• <no_oLreceive<L$et$> as defined in X12.22 as AK903, an alias for data element # 1 23; its 
value is a count of the included transaction sets received in the interchange by the Fll-translaton 

• <no_of_accepted_sets> as defined in X12.22 as AK904, an alias for data element # 2; its value 
is a indicates the number of the received transaction sets not-rejected by the Flhtranslaton 

• <fg_syntax_er_cd> as defined in X12.22 as AK905 - AK909, an alias for data element # 716; 
the possible values are included herein for reference. At least one occurrence shall be present 

The defined possible values for <fg_syntax^er_code> are as follows: 

1 Functional group not supported; 

2 Functional group version not supported; 

3 Functional group trailer missing; 

4 Group control number in functional group header and functional group trailer do not 
agree; 

5 Number of included transaction sets does not match actual count; 

6 Group control number violates syntax; 

1 0 Authentication key name unknown; 

1 1 Encryption key name unknown; 

1 2 Requested service (Authentication, Non-repudiation, or data protection) not available; 

1 3 Unknown security recipient; 

1 4 Unknown security originator, 

1 5 Syntax error in decrypted text; 

1 6 Security not supported; 

__ 1 7 I n correct mes sage le ngth (Encryption and Non-repudiation); 

18 Message authentication code failed; 

1 9 S1E Security End Segment missing for S1S Security Start Segment, 

20 S1S Security Start Segment missing for S1E Security End Segment; 

21 S2E Security End Segment missing for S2S Security Start Segment, 

22 S2S Security Start Segment missing for S2E Security End Segment 

NOTE - Code values 7, 8, and 9 are not defined in X1222, and hence are not used. 
6.3.1.13. Signature data types 

The following signature data types are defined by X9 for digitally signing several items in the interchange. 
6.3.1 .13.1 . Signature transaction set 

The <signature_Js> conveys the digital signature applied to this functional group as created by the 
originating financial institution. It also conveys information on the creation of the signature. When present, 
the signature enables a receiving application to authenticate the source of the signed data. 



Table 34 • STS: Signature TS element names 



STB: Signature TS 
element names 


Size 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<signature_ts> 












<trans_set_header> 






TS 


M 


M 


<signature_data> 






rsioi 


M 


M 


<signaturo> 






BIN 


M 


M 


<trans_set_trai!er> 






TE 


M 


M 



The data elements are defined as follows: 
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The defined possible values for <trans_seL_syntax_error_code> are as follows: 



1 


Transaction set not supported; 


2 


Transaction set trailer missing; 


3 


Transaction set control number in header and trailer do not match; 


4 


Number of included segments does not match actual count; 


5 


One, or more, segments contain errors; 


6 


Missing or invalid transaction set identifier, 


7 


Missing or invalid transaction set control number; 


8 


Authentication key name unknown; 


9 


Encryption key name unknown; 


10 


Requested service (Authentication, Non-repudiation, or data protection) not available; 


11 


Unknown security recipient, 


12 


Incorrect message length (Encryption and Non-repudiation); 


13 


Message authentication code failed; 


15 


Unknown security originator, 


16 


Syntax error in decrypted text; 


17 


Security not supported; 


19 


S1E Security End Segment missing for S 1S Security Start Segment; 


20 


S1S Security Start Segment missing for S1E Security End Segment; 


21 


S2E Security End Segment missing for S2S Security Start Segment; 


22 


S2S Security Start Segment missing for S2E Security End Segment. 



NOTE - Code values 14 and 18 are not defined in X1222, and hence are not used. 



Table 33 • AK9: FO response trailer element names 



AK9: FO response trailer 




Data 


Ret" 


Protocol 


Busbies 


element names 




type 




support 


s 

usage 


<tg_rasponse_trail8T> 






AK9 






<functionaL8roup_acleood0> 


01/D1 


(0 


AK901 


M 


M 


<no_ofJnduded_sets> 


01X16 


N 


AK902 


M 


M 


<no_of_recelved_sets> 


01/06 


N 


AK903 


M 


M 


<no_of,jicc8pt8<L.s£ts> 


01/06 


N 


AK904 


M 


M 


<ffl_syntax_er_cd> 


01/03 


ID 


AK905 


0 


B11 


<ffl_syntax-_ec.cd> 


01/03 


ID 


AKS08 


0 


B11 


<fg_syntax_er_cd> 


01X33 


to 


AKS07 


0 


B11 


<fg_syntax^er„ocl> 


01/03 


to 


AK908 


O 


B11 


<fg_syntajcer_cd> 


01/03 


ID 


AK909 


O 


B11 



Components of the <trans_$et_responsejtrailer> are defined as follows: 

• <functional_group_ack_code> as defined in X1222 as AK901 is an alias for data dement # 
715. The possible values are included herein for reference; 

The defined possible values for <functional_group_ack_code> are as follows: 

A Accepted; 

E Accepted, but errors were noted; 

M Rejected: Message authentication code (MAC) failed; 

P Partially accepted: at least one transaction set was rejected ; 

R Rejected; 

X Rejected: Content after decryption could not be analyzed. 
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• <data_element_reLno> as defined in X12.22: AK402, an alias for data element 725, conveys 
the XI 2 Data Dictionary's data element number; 

• <etement_syntx_er_cd> as defined in XI 2.22: AK4Q3, an alias for data element 723, the 
possible values are included herein for reference; 

• <value_of_bad_element> as defined in X1222: AK404, an alias for data element 724, conveys 
a copy of the bad elements value. 

The defined possible values for <element_syntx__er_cd> are as follows: 

1 Mandatory data element missing; 

2 Conditional required data element missing; 

3 Too many data elements; 

4 Data element too short; 

5 Data element too long; 

6 invalid character in data element; 

7 Invalid code value; 

8 Invalid date; 

9 Invalid time; 

10 Exclusion condition violated. 



Table 32 - AK5: Transaction set response trailer element names 



AK5: Transaction set response trailer 
element names 


Size 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<trans_set_response_trailer> 






AK5 






<trans_set_ack_oode> 


0101 


ID 


AK501 


M 


M 


<tKDfejse\_syntax_e^ 


0**03. 


. ID "." 


"AKSOfil 


6 Z 


B11 .. 


<trans_set_syntax_efror_code> 


01/03 


ID 


AK503 


O 


B11 


<trans_set_syntax_enor_oode> 


01/03 


ID 


AK504 


o 


B11 


<trans n set n syntax_errof_oodo> 


01*3 


ID 


AKSOS 


O 


B11 


<trans„set„syntax_error_code> 


01X13 


ID 


AK506 


o 


B11 



Components of the <trans_set_response_trailer> are defined as follows: 

• <trans_seLacK-Code> as defined in X12J22: AK501 is an alias for data element 717. The 
possible values are included herein for reference; 

The defined possible values for <trans^set^ack^code> are as follows: 

1 Accepted; 

2 Accepted, but errors were noted; 

3 Rejected: Message authentication code (MAC) failed; 

4 Rejected; 

5 Rejected: Content after decryption could not be analyzed. 

• <trans_set_syntax^error_code> as defined in X1222: AK502 - AK506 is an alias for data 
element 718. The possible values are included herein for reference. 
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Table 30 - AK3: Data segment note element names 



AK3: Data segment note 


Stre 


Data 


Ret. 


Protocol 


Business 


element names 




type 




support 


usage 


<data_segment_note> 






AK3 






<seflmenUd_code> 


02/03 


AN 


AK301 


M 


M 


<seoj>ositionjn_trans„set> 


01/06 


N 


AK302 


M 


M 


<*oop_W_coo»> 


01/04 


AN 


AK303 


O 


B11 


«egm8ncsynt)L-er„od> 


01/03 


to 


AK304 


o 


B11 


<segmenUsyntx_er_cd> 


01AM 


ID 


AK305 


o 


B11 


<segment_synt^_er„cd> 


01/03 


ID 


AK306 


o 


B11 


<segment,syntx_er_cd> 


01/03 


to 


AK307 


o 


B11 


<segment„syntx_er„cd> 


01 A3 


ID 


AK308 


o 


B11 



Components of the <trans_set_response_header> and <trans_seOesponse_traiter> are defined as 
follows: 

• <segmenl_id_code> as defined in X1222: AK301, an alias for data element 721 it conveys the 
value of the data segments identifier (e.g., "IVS") found in the data segment being 
acknowledged; 

• <seg_positionJn_trans_set> as defined in X12J22: AK3Q2, an alias for data element 719, 
identifies the segments position relative to the Transaction Set Header; 

• <toopJd_code> as defined in X1222: AK303, an alias for data element 447, conveys the loop 
identifier if the segment being acknowledged is a Loop Header, or Loop Trailer; 

— <segment^synt)^er-cd> as defined in X12 

the possible values are included herein for reference. 

The defined possible values for <segmenL.syntoc_er_cd> are as follows: 

1 Unrecognized segment identifier; 

2 Unexpected segment; 

3 Mandatory segment missing; 

4 Loop occurrences exceed maximum times; 

5 Segment exceeds maximum use; 

6 Segment not in defined transaction set; 

7 Segment not in proper sequence. 



Table 31 - AK4: Data element note element names 



AK4: Data element note 
element names 


Size 


Data 
type 


Ret 


Protocol 
support 


Business 
usage 


<daia_dement_rtot8> 






AM 






<eUK»ibonJn_seflment> 


01/02 


N 


AK401 


M 


M 


<data_etement„ref.no> 


01/04 


N 


AK402 


0 


B11 


<etefnent_syntx n er.jcd> 


01*0 


ID 


AK403 


M 


M 


<value_oJjbad_eJemem> 


01/99 


AN 


AK404 


0 


811 



Components of the <data_element_note> are defined as follows: 

• <ei_position_in_&egment> as defined in X1222: AK401, an alias for data element 722; 
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Table 27 - Data segment response loop element names 



Data segment response loop 
element names 


So* 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<dat£Lsegment_responsejoop> 












<data„seqrnent_.note> 






AK3 


M 


M 


<data_elemenLnote> 1 








O 


B11 



1 - max 99 instances 



The syntax of components <data_segment_note> and <data„element_note> shall be as defined in 
6.3.1.12.4. The data element note <data_element_note> is used to identify the position of a single data 
element whose value is syntactically incorrect. 

6.3.1.12.4. X12 AK1 - AK5, AK9 definitions 

The X12 defined data structures for AK1 * AK5 and AK9 segments are included herein for reference. AK1 
and AK9 segments identify the subject functional group; AK2 and AK5 identify the subject transaction set; 
segments AK3 and AK4 identify errors detected at the segment level within the subject transaction set. 

Protocol support: Mandatory 

Business usage: Mandatory 



Table 28 - AK1: FG response header element names 





AK1: FG response header 
element names 


Site 


Data 
type 


Ref 


Protocol 
support 


Business 
usage 




4g_re$ponse_header> 






AK1 










AN 


~AK101~~ 








<fu7Ktk>nal_group„kb- 


M 


M 




<hjnctton_contrd_number> 


01/09 


AN 


AK102 


M 


M 



Components of the <fg_re$ponse_header> are defined as follows: 

• -afunctional _groupJd> as defined in 6.3. 1. 1. 1. of this specification, it conveys the value found 
in the GS segment (QS01) of the functional group being acknowledged; 

• <function_controLnumber> as defined in 6.3. 1. 1.6. of this specification, it conveys the value 
found in the GS segment of the functional group being acknowledged; 



Table 29 - AK2: Transaction set response header element names 



AK£ Trans set response header 
element names 


Size 


Data 
type 


Ref 


Protocol 
support 


Business 
usage 


<trans_seCre$ponse_header> 






AK2 






<trans_set_jcfc> 


03/03 


AN 


AK201 


M 


M 


<trans_seUcontrd_number> 


04/09 


AN 


AK202 


M 


M 



Components of the <trans_set_response_rteader> are defined as follows: 

• <trans_setjd> as defined in 6.3. 1.3. 1. of this specification, it conveys the value found in the ST 
segment (ST01) of the transaction set being acknowledged; 

• <trans_set_controLnumber> as defined in 6.3. 1.32. of this specification, it conveys the value 
found in the ST segment of the transaction set being acknowledged. 
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Table 25 - 997: Functional acknowledgment transaction set element names 



997: Functional acknowledgment 
transaction set 
element names 


Sin 


Data 
type 


Raf* 


Protocol 
support 


Business 
usage 


<functionaJ_acKJransaction_set> 












<lrans_set_header> 






ST 


M 


M 


<fg_res Donse_header> 






AK1 


M 


M 


<trans_set^rBSponso_ toop> 








M 


M 


<fg_response_traiter> 






AK9 


M 


M 


<trans_8et_trafler> 






SE 


M 


M 



Components of the <f unctionaLack_transaction_$et> are defined as follows: 

- The syntax of Transaction Set Header (<trans_setjheader>) shall be as defined in 6.3. 1.3; 

- 77ie syntax of Functional group response header <fg_response_header> shall be as defined in 
6.3.1.12.4 

- The syntax of Transaction Set response loop <trans_seLresponseJoop> shall be as defined in 
6.3.1.122 

- 77i© syntax of Functional group response trailer <fgjresponsejtraller> shall be as defined in 
6.3.1.124 

- The syntax of Transaction Set Trailer (<trans_setjtraller>) shall be as defined in 6.3. 1.4. 

„The value jot the TransactiDn-SW JdentifleU<trans_se^ 
(<trans_seOieader>) shall be "997'. 

&3.1.1Z2. Transaction set response loop 

The Transaction Set Response Loop (<trans_set_responsejoop>) data structure reports syntax errors 
detected at the transaction set level for the subject transaction set. ft is defined in XI 2.22 and included 
here for reference. 

Table 26 - Transaction response loop element names 



AK2: Transaction set response loop 
element names 


Stee 


Data 
type 


Ret 


Protocol 
support 


Business 
usage 


<trQns^SGt__wsport$oJk)Op> 












<trans_set_response_header> 






AK2 


M 


M 


<datacsegmenLresponso„toop> 








M 


M 


<trans_set_response_trailer> 






AK5 


M 


M 



The syntax of <trans_set_response_header> and <trans.se|_re$ponse_trailer> shall be as defined in 
6.3.1.12.4 

6.3.1.123. Data segment response loop 

The Data Segment Response Loop <segment w responseJoop> data structure reports detected syntax 
errors for data segments within the subject transaction set It is defined in X12.22, and included here for 
reference. 
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Protocol support: Mandatory 
Business usage: Mandatory 
6.3.1.11.2. Binary data 

The Binary Data <binary_data> element conveys the data in its encoding as presented by Fll-sy stem- 
user. 

Size: 01/(10 15 ~1) 
Type: B 

<binaiy_data>(01/(10 15 -1)) ::=<bmary> 
Values: A stream of unconstrained bytes. 
Protocol support: Mandatory 
Business usage: Mandatory 

6.3.1.12. Functional acknowledgment functional group 

The Functional Acknowlegment Functional Group <functional_ackJg> structure is intended to 
acknowledge that the received interchange is or (is not) syntactically correct. It comprises a Functional 
Group Header and a Functional Group Trailer which encapsulate the Transaction Set Header and Trailer. 
It is defined in X12.22 and included here for reference. It shall always be generated if interchange syntax 
checking was requested by the originator of the interchange. 



Table 24 - FA: Functional acknowledgment functional group element names 



FA: Functional acknowledgment 
. . _ . .... . -dement names — 


Size 


Data 
type 


Ref 


Protocol 
support 


Busines 

s - 












usage 


<functionaLack_fg> 












<fg_header> 






GS 


M 


M 


<tuncttonaf__ack^toBnsaction_set> 








M 


M 


<tg_trafler> 






GE 


M 


M 



Components of the <f unctiona!_ack__fg> are defined as follows: 

- Functional Group Heading (<fgjieader>) is defined in 6.3. 7. 1; 

The value of the Functional Group ID (<functionat_groupJd>) component of the Functional 
Group Header (<fg_header>) shall be *FA 0 , 

- Functional acknowledgement transaction set <functionaLack_transaction_set> is defined in 
6.3.1.12.1 

- Functional Group Trailer (<fg_trailer>) is defined in 6.3. 1 £ 
6.3.1 .1 2.1 . Functional acknowledgment transaction set 

The Functional acknowledgment Transaction Set <functional_acK_transaction_set> conveys the 
segments which constitute a functional acknowledgment. It comprises a Transaction Set Header and a 
Transaction Set Trailer which encapsulate the Functional Acknowledgment message segments. It is 
defined in X12.22 and included here for reference. 
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Table 22 - S2E: TS Security trails element names 



TS security traQer 
element names 


Size 


Data 
type 


Ret. 


Protocol 
support 


Business 
usage 


<ts_securfty_tra!te r> 






S2E 






<message_aulh_code> 


09A» 


AN 


997 


M 


M 



6.3.1.10.1. Message authentication code 

The Message Authentication Code <mes$age_auth_code> contains a MAC that is used by the recipient 
to validate the identity of the originator and the integrity of the contents of this transaction set Although 
the contents of the transaction set is "in the clear", it enables the recipient to detect manipulation of the 
original contents of this transaction set, i.e., everything after the <tr> in this functional group's S2S 
segment up to, but excluding the start of this transaction sefs S2E segment 

This data element has the same semantics and syntax as 6.3.1.8.1 ., except that it is being applied to a 
transaction set. 

6.3.1.11. Bin segment 

The Binary Segment <bin.segment> conveys the length, and the entire binary entity, as a binary object 
whose semantics and syntax are understood by the originating and receiving applications in accordance 
with the requirements of this standard. This standard uses it to represent the structure of a User Data 
segment, a Financial Data segment, Signature data segment, and a View Binary Data segment It is 
defined in X 12,22, and included here for reference. 

For example, this data element may be used to convey. 

- The entire X9.37 structured electronic check data, and the Financial Data Functional Group, 

- Individual instances of raster image encoding information within an instance of item views loop, 
or 

Privately agreed additional selection criteria when used in the context of a Query Request 
transaction set 



Table 23 - Binary Segment element names 



Binary Segment 
element names 


Sbe 


Data 
type 


Ref. 


Protocol 
support 


Business 
usage 


<bln_segment> 






BIN 








oms 


N 


784 


M 


M 




oino u .i 


B 


7B5 


M 


M 



6.3.1.11.1. Length of Unary data 

The Length <!ength_of_binary__data> element contains a value which gives the length of the 
subsequent binary data in bytes. 

Size: 01/15 

Type: N (constrained to be an unsigned integer) 
<tength_ofJ)inary_data> (01/15) ::= <unsigned Jnteger> 
Values; 1 through 10 15 -1 
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6.3.1.9.5. Authentication service code 

The Authentication Service Code <authent_serv_code> identifies the character set used to encode the 
MAC. Its values are defined as either X9.9 binary code or X9.9 coded character set. 

This data element has the same syntax as 6.3.1 .7.5, except that it applies to a transaction set 

<authent_serv_code> (01/01) ::= <id> I <x9_9_binary_data> I <x9_17_std_value> 

<x9_9_binary_data> ::= "1" 

<x9_17_std_valuo> ::= "2° 

6.3.1.9.6. Encryption key name 

The Encryption Key Name encryption Jcey_name> is the name of the key used to encipher the 
contents of this functional group. 

This data element has the same semantics and syntax as 6.3.1.7.6, except that it applies to a transaction 
set 

<encryption_key_name> (01/16) ::= <string> 

6.3.1 .9.7. Encryption service code 

The Encryption Sen/ice Code <encryption_serv_code> represents the encryption mode and 
transmission filter specification of filtering binary ciphertext data into transmrttable text 

This data element has the same syntax as 6.3.1.7.7, except that it applies to a transaction set 

<encryption_serv„code> (01/03) ::= <4d> I <cbc_no_filter> I <cbc_hexjilter> I <cbc_asciLfifter> I 
<cbc_ascfi_baudot_filter> I <cbc H mutually v defined_filter> I <cfb_8_no_filter> I <cfb_8_he*Jilter> I 
<cfb_8_asdi_filter> I <cfb_8_ascIIJ>audot_fiIter> 

— <cbcjw>-f0ter> ::=^20— 

<cbc_hexjitter> ::= "21 " 

<ctoc_ascfl_filter> ::= "22° 

<etoc_ascH_baudot_filter> "23" 
<cbc_mutually_defined_fitter> ::= m ZT 
<cfb w 8_no_fitter> ::= "40° 

<cfb_8_hexjitter> "41" 
<cfb_8_ascQ JUter> ::= °42° 

<cfb_8_ascn_baudot_fitter> ::= "43° 

6.3.1 .9.8. Length of data 

The Length Of Data <length_of_data> element is defined as the number of bytes in the contents of the 
transaction set being protected. It starts from the first byte of the next segment, and includes all bytes up 
to, but excluding, the start of the S2E segment 

This data element has the same syntax as 6.3.1 .7.8., except that it is being applied to a transaction set 
<tength_of_data> (01/1 8) ::= <numerio 

6.3.1 .9.9. Initialization vector 

The Initialization Vector <inftialization_vector> identifies the starting point of encrypted data. This data 
element has the same syntax as 6.3.1 .7.9, except that It applies to a transaction set. 

<inltialization_vector> (16/16) ::= <string> 
6.3.1.10. Transaction set security trailer 

The following Transaction Set Security Trailer (S2E) is used in this standard in Acknowledgments and 
Query Request transaction sets only. The definition is specified in X12.22 and X12.58. The S2E structure 
supports both data integrity and data protection. 
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Table 21 • S2S: TS security element names 



S2S: FG security 


Size 


Data 


Ret. 


Protocol 


Business 


element names 




type 




support 


usage 


<ts„securtty_h£ader> 


















S2S 






<sacurtty„type> 


O2J02 


10 


990 


M 


M 


<securtty.ortfl.name> 


04/16 


AN 


824 


M 


M 


<securfty_recip_name> 


04/16 


AN 


82S 


M 


M 


<authem_key_name> 


01/16 


AN 


991 


CI 


B9 


<authenLserv_code> 


01/01 


10 


992 


CI 


B9 


<encfyptton_key_name> 


01/16 


AN 


993 


C11 


B9 


<encTVPtion„serv_codo> 


01/03 


to 


994 


C11 


B9 


<tenqth_of_data> 


01/16 


N 


99S 


C11 


B9 


<initiaIi2ation_vectoT> 


18/16 


AN 


998 


C11 


B9 



The Transaction Set Security Header <securrty_S2S> is specified here and in annex 6. The transaction 
set security header data elements, defined in X12.22 and X 12.58, appear below for reference: 

6.3.1 .9.1 . Security type 

The Security Type <securrty_type> identifies the type of security being applied. 

This data element has the same syntax as 6.3.1 .7.1 , except that it applies to a transaction set 

<securtty_type> (02/02) <ta> I 

<authentication_onty> I <authentication_and_data _protection> I <data_protection_onry> 

<airthenticatlon_onty> — _::=.!!AA" — — 

<authentic£tion_and_dataj>rotectiort> ::= "BB" 
I <data.protectlon.only> ::= "EE" 

6*3.1 .9.2. Security originator name 

The Security Originator Name <security_orig_name> identifies the originator of the security mechanism 
at the Transaction Set level of the Interchange. 

This data element has the same syntax as 6.3.1 .7.2. except that it applies to a transaction set 
<security_oritj_!\ame> (04/16) ::= <string> 

6.3.1 .9.3. Security recipient name 

The Security Recipient Name <securrty_recip.name> identifies the intended recipient of the security 
mechanism. 

This data element has the same semantics and syntax as 6.3.1 .7.3., except that it applies to a transaction 
set 

<security_recip_name> (04/16) <string> 

6.3.1 .9.4. Authentication key name 

The Authentication Key Name <authent w key_name> identifies the name of the key used to generate the 
MAC found In the <ts_security_trailer>. Its syntax and values are defined in X12. 

This data element has the same syntax as 6.3.1.7.4, except that it applies to a transaction set 

<authenUcey_name> (01 /16) ::= <string> 
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Table 20 - S1£: FG security trailer element names 



FG security trailer 
clement names 


Size 


Data 
type 


Ret 


Protocol 
support 


Business 
usage 


<fg_security_trailer> 






S1E 






<message_auth_code> 


09A» 


AN 


997 


M 


M 



6.3.1 .8.1 . Message authentication code 

The message authentication code <message_auth_code> contains a MAC that is used by the recipient 
to validate the source and the integrity of the contents of this functional group. Although the contents of 
the FG is "in the dear," it is designed to enable the recipient to detect manipulation of the original 
contents of this FG; i.e., everything after the <tr> in this functional group's S1S segment up to. but 
excluding, the start of this functional group's S1 E segment. 

Size: 09/09 
Type: AN 

<message_auth_code> (09/09) ::= <string> 

Values: Locally determined 

The data element consists of 4 hexadecimal coded characters (i.e., characters from the set 0..9, 
A..F), a separator character (space), and 4 hexadecimal coded characters. If the data element is 
not used, it shall be fitted only with space characters. The space character shall be encoded as 
defined in table 6 specification. 

-Protocol support— Mandatory- 

Business usage: Mandatory 

6.3.1.9. Transaction set security header 

The following Transaction Set Security Header <ts_securfty_header> structure may be used wfth 
acknowledgments and Query Requests transaction sets only to convey data protection mechanisms, and 
simple authentication security mechanisms, like passwords and MAC codes. The definition is specified in 
X12.22 and X12.58, and included herein for reference. The S2S structure supports both data protection 
and a minimal form of data integrity. 

The syntax and values for the transaction set security header elements are defined in 6.3.1.7. 

Strong authentication and non-repudiation facilities are provided in 6.3.1.9 of this specification by means 
of conveying a digital signature. 
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Values: 20= X9.23 Cipher block chaining (CBC), no fitter (binary cipher text) 

21 = X9.23 Cipher block chaining (CBC), Hexadecimal fitter 

22 = X9.23 Cipher block chaining (CBC), ASCII fitter 

23 = X9.23 Cipher block chaining (CBC), ASCtl/B AUDOT filter 
2Z= X9.23 Cipher block chaining (CBC), mutually defined fitter 

40 ~ X9.23 CFB-8 (Cipher Feedback), no fitter (binary cipher text) 

41 = X9.23 CFB-8 (Cipher Feedback), Hexadecimal filter 
42= X9.23 CFB-8 (Cipher Feedback), ASCII filter 

43 = X9.23 CFB-8 (Cipher Feedback), ASCIl/BAUDOTfitter 

Protocol support: Conditional, valid only if required by or applicable to the security mechanism utilized. 

Business usage: Conditional, shall be present only to specify or to convey security features or security 
mechanisms. 

6.3.1 .7.8. Length of data 

The Length Of Data <length_of_data> element is defined as the number of bytes in the contents of the 
functional group being protected. It starts from the first byte of the next segment, and includes all bytes up 
to but excluding the start of the S1 E segment 

Size: 01/18 

Type: N 

<*engttuof_data> (01/18) <numerio 
Values: locally determined 

Protocol support: Conditional, valid onty if required by or applicable to the security mechanism utilized. 

Business usage: — C^nditionaJ r 6hali be present only to specify or-to convey security features or security — 
mechanisms. 

6.3.1.7.9. Initialization vector 

The Initialization Vector <initia!ization_vector> element Identifies the starting point of encrypted data. A 
new initialization vector shall be used for each message. It is the archival representation of a 64-bit value 
expressed in hexadecimal notation (HEX) as 16 ASCII characters from the set of characters (0..9, A..F). 
The 64-bit value Is used to increase security by introducing cryptographic variance and to synchronize 
cryptographic equipment 

Size: 16/16 

Type: AN 

<inhlaltzation_vector> (16/16) <string> 

Values: String characters constrained to "0"-°9* and to upper case characters "A" through "F which 
are used to represent a hexadecimal value. 

Protocol support: Conditional, valid only if required by or applicable to the security mechanism utilized. 

Business usage: Conditional, shall be present only to specify or to convey security features or security 
mechanisms. 

6*3.1 Jl. Functional group security trailer 

The following Functional Group Security trailer (S1 E) structure is used throughout this standard and is 
defined in X1222 and X12.58. The S1S structure supports both data integrity and data protection. It shall 
be last in the functional group. 
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6-3.1 .7.5. Authentication service code 

The Authentication Service Code <authent.8erv.code> element identifies the character set used to 
encode the MAC. Its values are defined as either X9.9 binary code or X9.9 coded character set. 

Size: 01/01 

Type: ID 

<authent_serv_code> (01/01) ::= <Jd> I <x9_9_blnary__data> I <x9j17__std_value> 

<x9_9_binary_data> ::= "I" 

<x9_17_std_value> ::= m 2 tt 

Values: 1 means X9.9 binary data 

2 means X9.9 coded character set, entire message, no editing (the standard value for X9.1 7 
Authentication with the data element separator expressed as an LF character for the calculation 
of the MAC) . 

Protocol support Conditional, shall be supported if security at the present structural level is supported.. 

Business usage: Conditional, shall be present only to specify or to convey security features or security 
mechanisms. 

6.3.1.7.6. Encryption key name 

The Encryption Key Name <encryption_key_name> element conveys the name of the key used to 
encipher the contents of this functional group. The name Is mutually known to the security originator and 
the security recipient, is unique for this relationship, and allows a particular key to be specified. Its value is 
the subject of the Business Practices Agreement. 

_„Size:_ 01/16 

Type: AN 

<encryption_key_name> (01/16) ::= <string> 
Values: locally defined and mutually agreed. 

Protocol support Conditional, valid only if required by or applicable to the security mechanism utilized.. 

Business usage: Conditional, shall be present only to specify or to convey security features or security 
mechanisms. 

6.3.1 .7.7. Encryption service code 

The Encryption Sen/ice Code <encryptlon_serv_code> element represents the encryption mode and 
transmission fitter specification of filtering binary ciphertexl data into transmittable text 

Size: 01/03 

Type: ID 

<enciyption_serv_code> (01/03) ::= <id> I <cbc_no_filter> I <cbc_hex_filter> I <cbc_asclLfilter> I 
<cbc_asdLbaudot_filter> I <cbc_mutuaHy_defined_fQter> I <cfb_8_no Jflter> i <cfbJLhex_filter> I 
<cfb_8_asciLfilter> I <cfb_8_asciLbaudot_filter> 



<cbc_no_fitter> ::= "20" 

<cbc_hex_filtei> ::= *21 " 

<cbc_ascii_fifter> ::= m 22 a 

<cbc_ascji_baudot_fifter> ::= *23" 

<cbc_mutually_defined_fitter> ::= B 2Z* 

<cfb_8_no_filtei> ::= "40° 

<efb_8 J»exJitter> ::= "41 ° 

<cfb_8_asciLfilter> ::= "42" 

<cfb_8_ascil_baudot_filter> ::= "43" 
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<authentication_onty> ::= a AA° 

<authentication H and_data_protection> :v= "BB" 
I <data_protection_only> ::= "EE" 

Values: AA Authentication, no encryption; 
BB Authentication and Encryption; 
EE Encryption, no authentication. 

Protocol support: Mandatory 

Business usage: Mandatory 

6.3.1 .7.2. Security originator name 

The Security Originator Name <security_orig_name> element identifies the originator of the security 
mechanism, i.e., the entity that performs authentication or encryption on data to be interchanged. 

Size: 04/16 

Type: AN 

<securfty.orig.name> (04/16) <string> 
Values: Locally determined 
Protocol support: Mandatory 
Business usage: Mandatory 

6.3.1 .7.3. Security recipient name 

The Security Recipient Name <securityjrecip_name> element identifies the intended recipient of the 

— security-mecr^ismrLe.T-the- 

tnterchange. 

Size: 04/16 

Type: AN 

<securtty_redp_name> (04/16) ::= <string> 
Values: Locally determined 
Protocol support Mandatory 
Business usage: Mandatory 

6.3.1.7.4. Authentication key name 

The authentication key name <authentjcey_name> element identifies the name of the key used to 
generate the message authentication code (MAC) found in the <fg_securfty_trai!er>. Its syntax and 
values are defined in X12. 

Size: 01/16 

Type: AN 

<authenUcey_name> (01/16) <string> 

Values: 

Protocol support: Conditional, shall be supported if security at the present structural level is supported. 

Business usage: Conditional, shall be present only to specify or to convey security features or security 
mechanisms. 
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6.3.1*6.1. Loop ID 

The Loop ID <Joop_ld> element is a control identifier that names the ending loop type. The value is that 
of the Loop ID carried in the Loop Header for this loop. 

The syntax and values of this data element are that of <loop_id> defined in 6.3.1 .5.1 . 
6.3.1 .7. Functional group security header 

This section 6.3.1.7.1-6.3.1.7.9 defines data elements for the Functional Group Security Header. The 
syntax and the values of this functional group header are also used in Transaction Set Security Header, 
see 6.3.1.9. 

The following Functional Group Security Header (S1S) structure is used throughout this standard, and is 
defined in X 12.22 and X12.58. The S1S structure supports both data integrity and data protection. 

• Depending upon the cryptographic scheme used, it is possible to validate the Data Integrity Check 
and to authenticate the origin of its transaction set. 

• An authentication facility is provided in "signature ts" of this specification by means of conveying a 
digital signature. When a Signature TS is also present, the value of the <authent_key_name> data 
element also identifies the mechanism used to create the originator's digital signature carried therein. 

• Content Confidentiality is not supported by this technique; subsequent segments are passed in the 
clear. 



Table 19 - S1S: FG Security element names 



SIS; FG Security 


Stee 


Data 


Ret 


Protocol 


Business 


clement names 




type— 




support 


usage 


<fg_security_header> 












<secvrity_SxS> 






sis 






<securtty_type> 


02/02 


ID 


990 


M 


M 


<securfty orig_name> 


04/16 


AN 


624 


M 


M 


<securttyjnedp_name> 


04/16 


AN 


625 


M 


M 


<authent_key_name> 


01/16 


AN 


991 


C1 


B9 


<authent_sefv_code> 


01/01 


to 


992 


CI 


B9 


<encryptjon_key_narne> 


01/16 


AN 


993 


C11 


89 


<encryption_s8rv_.code> 


01/00 


10 


994 


C11 


B9 


<tength_of_data> 


01/18 


N 




C11 


B9 


<inttafizatlofUV8Ctor>- 


16/16 


AN 




C11 


B9 



The functional group security header <security_S1S> is specified in this clause and annex A. The 
following are the subelements in security S1S: 

6.3.1 .7.1. Security type 

The Security Type <security_type> element identifies the type of security being applied. 
Size: 02/02 
Type: ID 

<securtty_type> (02/02) <ld> I 

<authentication_only> I <authentication_and_da1a_protectiort> I <data_protectlon_only> 
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The value is that of the <trans_set_control_number> carried in the corresponding transaction set 
header. 

<trans_set_controLnumber>(04/09) ::= <strlng> 
6.3.1.5. Loop header 

The following Loop Header (LS) structure is primarily used in the context of imaged Hems earned in the 
Item views functional group . Its syntax is as defined in X 12.22. It defines the beginning of each loop, 
which may contain hem subgroups, Hem data, or item views. There shall be one loop header for each 
loop, and it shall be first in the loop. All loops are limited to 999,999 Iterations unless otherwise explicitly 
specified in this standard. 



Table 17 - LS: Loop header element names 



LS: Loop header 
element names 


Size 


Data 
type 


Ret 


Protocol 
support 


Business 
usage 


<toop.neader> 






LS 






<toop_W> 


01AM 


AN 


447 


M 


M 



The following define the elements in the loop header. 
6.3.1-5.1. Loop ID 

The Loop ID <loop_id> element is a control identifier that names the current loop type in the Loop 
Header. The same syntax, semantics, and value are used In the loop trailer, see 6.3.1 .6.1 . 

Size: 01/04 

.-.Tjrpe: AN 

<loopjd>(01/04) ::s<8tring>l - Only X9.4S registered values 

<rtenusubgroup_or_.query_re<i> I <Kem_data> I <rtem_view> 

<ltetn_subgroup H or_quety_req >::= "1" 
<ftetn_data> "2" 
<Hem_.view> ::o *3 m 

Values: "1 " means Item Subgroup or Query Request, depenefng on functional group type, 
means Item Data 
'3* means Item View 

Protocol support Mandatory 

Business usage: Mandatory 

6.3.1.6. Loop trailer 

The following Loop Trailer (LE) structure is used throughout this standard and is as defined in X 12.22. It 
defines the end of a loop. It shall be last in a loop. There shall be one for each loop, and it ends the 
current bop. 



Table 18 - LE: Loop trailer element names 



LE: Loop trailer: 
element names 


Size 


Data 
type 


Ret 


Protocol 
support 


Business 
usage 


<tocp_trail 6 r> 






LE 






4oop.Jd> 


01/04 


AN 


447 


M 


M 



The following are the data elements in the loop trailer: 
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6.3.1 .3.2. Transaction set control number 

The Transaction Set Control Number <trans_set_controLnumber> element conveys a value used to 
provide matching control between the transaction set header and the transaction set trailer. Its value, 
determined by the originator of the transaction set, is unique across all transaction sets within a specific 
functional group. The value assigned in the header must match the value assigned in the trailer, see 
6.3.1.4.2. 

Size: 04/09 

Type: AN 

<trans_8et_controLnumber>{04/09) <string> 

Values: The value is to be the same value as carried in the corresponding Transaction Set Header and 
Trailer 

Protocol support: Mandatory 
Business usage: Mandatory 
6.3.1.4. Transaction set trailer 

The following Transaction Set Trailer (SE) structure is used throughout this standard to identify the end of 
a named transaction set. The <no_of_included_segment$> provides a level of control to indicate the 
total number of segments included in the transaction set, which is named by the value of 
<trans_set_controLnumber>. Its syntax is defined in X12.22 and included here for reference. 



Table 16 - SE: TS trailer data element names 



SE - Transaction set trailer 
dement names 


Size 


Data 
type 


Ret. 


Protocol 
support 


Business 
usage 


<tnms_3et_trailer> 






SE 






<number_ofJnduded_segments> 


01/10 


N 


96 


M 


M 


<trans„seCoontrol_number> 


0*09 


AN 


329 


M 


M 



The Transaction Set Trailer <trans_set_trailer> is provided for control purposes. It shall be last in the 
transaction set. It is composed of the following subelements: 

6.3.1 .4.1 . Number of included segments 

The Number of Included Segments <number_ofJnciuded_segments> element conveys a count of the 
total number of segments included in this transaction set. It is provided for control purposes. 

The value shall include the Transaction Set Trailer. Header, and every segment in between. 

Size: 01/10 

Type: N 

<nunr>ber_of_l nd uded_segments> (01/10)::= <numerio 
Values: Calculated value 
Protocol support Mandatory 
Business usage: Mandatory 

6.3.1.4.2. Transaction set control number 

The Transaction Set Control Number element is provided to correlate a Transaction Set Trailer to its 
corresponding Transaction Set Header. Syntax and semantics for the transaction set control number are 
defined in 6.3.1.3.2. The value is the same as the value carried in the transaction set control number in 
the transaction set header. 
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The syntax is defined in 6.3.1.1.6. 

Values: Shall match the <function.controLnumber> in the associated functional group header. 
Protocol support* Mandatory 
Business usage: Mandatory 

6.3.1.3. Transaction set header 

The following Transaction Set Header (ST) structure is used throughout this standard to identify the start 
of a group of segments that share a common bond. Its syntax is defined in X 12.22 and included here for 
reference. 



Table 1 5 - ST: Transaction set header element names 



ST -Transaction Set Header 
element names 


Size 


Data 
type 


Ret 


Protocol 
support 


Business 
usage 


<trans_set_header> 






ST 






<trans_seUd> 


03/03 


AN 


143 


M 


M 


<trans„set_control_number> 


04O9 


AN 


320 


M 


M 



The Transaction Set Header is used to indicate the information common to the set of transactions. It shall 
be first in the transaction set. 



6.3.1.3.1 . Transaction set ID 

The Transaction Set ID <trans_set_id> element conveys a value which identifies the type of this 
transaction set Its type shall be selected in accordance with the X12 function header type that precedes 

"it: 

Size: 03/03 
Type: AN 

<trans_seUd> (03/03) ::= <string> I - Only X9.46 registered values are used 

<financlal_data_set> I <ltem.group.8et> I <apptication_acK_set> I <query_requests_set> I 
<slgnatures_8et> I <functionaLacK_set> 

<flnaftcfaLdata_.set> :» •FTS" 

<rtem_grotip_set> ::= ■ITS a 

<appllcation v acK.set> ::= "ATS" 

<query_requests_set> ::= "QTS" 
<signatures.S6t> "STS° 

<functionaf_aclL_set> ::= "997* - imported from X12 - 997 functional acknowledgment 

Values: m FTS m means Financial Data transaction set 
'ITS' means Item Group transaction set 
'ATS' means Application Acknowledgment transaction set 
*QTS m means Query Request transaction set 
*STS' means Signature transaction set 

"997* means Functional Acknowledgment transaction set 

Protocol support: Mandatory 

Business usage: Mandatory 
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6.3.1.1.8. Version 

The Version <version> identifies the X12 and X9 version and release numbers, respectively, to which 
this functional group conforms. 



Size: 01/12 
Type: AN 
<version> (01/12) 



: <string>- bytes 1-6: use the value '003050" 
- bytes 7-12: use the values '001001' 



Values: Character positions 1-3: 
Character positions 4-6: 
Character positions 7-9: 
Character positions 10-12: 

Protocol support: Mandatory 

Business usage: Mandatory 

6.3.1.2. Functional group trailer 



■003" to indicate X12 (1994) version, 

"050" to indicate X12 (1994) release, 

"001" to indicate the 1995 version of the X9.46 standard, 

"001" to indicate the 1 995 release of the X9.46 standard. 



The following Functional Group Trailer (GE) structure is used throughout this standard to identify the end 
of a named functional group. The <no_included_sets> provide a level of control to indicate the 
originator's perception of the number of sets of transactions included in the functional group, which is 
named by the value of <function_control_number>. Its syntax is defined in X 12.22 and included here 
for reference. 



Table 14 • GE: Function trailer element names 







-Size— 


—Data- 
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"Business" 
usage 




<fg_trafler> 






GE 






<noJncluded_sets> 


01A6 


N 


97 


M 


M 


<function_conirol_nufnbef> 


01/39 


N 


28 


M 


M 



The function trailer <fg_trailer> is the trailer of the function group. It shall be last in the functional group. 



6.3.1 .2.1 . Number of included sets 

The Number Of Included Sets <no_included_sets> conveys a value containing the count of the number 
of transaction sets included in this functional group. It is provided by the application sender, and used lor 
control purposes by the application receiver to ensure receipt of the correct number of transaction sets. 

Size: 01/06 

Type: N 

<noJncluded_sets> (01A)6) ::= <numerio 
Values: Count of number of transaction sets 
Protocol support Mandatory 
Business usage: Mandatory 

6.3.1 .2.2. Functional group control number 

The Functional Group Control Number <function_controLnumber> conveys a value which is used to 
control the functional group. It shall have the same value as its counterpart in the associated 
<fg_header>. 
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Protocol support: Mandatory 

6.3.1 .1 J5. Functional group time 

The Functional Group Time <fg_time> specifies the creation time of this functional group. The time value 
represents the local time of the institution creating this functional group. 

For the purpose of this standard, the value shall always include values for hours, minutes and seconds, 
i.e., contain six digits. 

Size: 04/06, this standard shall use 6 digits 
Type: TM 

<fg_time> (04/08) ::= <time> - The originator's LOCAL time, not GMT 

Values: HHMM[SSFF where HH represents hour, MM represents minutes, [SSJ represents seconds. Per 
X12, the inclusion of seconds is optional as indicated by the [ ] notation. 

shall be 00 through 23 
MM shall be 00 through 59 
SS shall be 00 through 59 
FF shall be 00 through 99 

Protocol support Mandatory 

Business usage: Mandatory 

6.3.1 .1 .6. Functional group control number 

The Functional Group Control Number <function_controLnumber> conveys a unique value which is 
used to control the functional group. It shall be unique within this interchange, and across all interchanges 

origtnaled.by.a.senderJor_a-spec^ 

functional group. 

The value is also used in Functional Group Trailer, see 6.3.1 .2.2. 
Size: 01/09 
Type: N 

<function_contn>Lnumber> (01/09) ::= <numerio 

Values: Locally determined and assigned. 
Protocol support Mandatory 
Business usage: Mandatory 

6.3.1.1.7. Standard 

The Standard <standard> identifies the standard to which the functional group conforms. 

Size: 01/02 
Type: AN 

<standant> (01/D2) <string>- the value 'X9 m is used 

Values: 'X9" 

Protocol support: Mandatory 
Business usage: Mandatory 
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73* means Query Requests 

"80 through 99° reserved for private types 

m FA m means Functional Acknowledgment 

Protocol support: Mandatory 

Business usage: Mandatory 

6.3.1 .1 J2. Application sender ID 

The Application Sender ID <app_senderjd> identifies the originator of the functional group's data. The 
value is registered by the same authority as the sender's <inter_id_qualifier> value defined in 6.2.3.3.1. 

If the sender is a bank (i.e. the <inter_id_qualtfier> in the ISA header is °17 B ), the application sender ID 
shall be the bank's routing number. If the value of <interjd_qualifier> is other than "17°, the value of this 
data element shall be as registered by that entity. 

Size: 02/15 
Type: AN 

<app_senderjd> (02/1 5) ::= <string> 
Values: 9 digits long. 
Protocol support: Mandatory 
Business usage: Mandatory 

6.3.1 .1 .3. Application receiver ID 

The Application Receiver ID <app_receiver_id> identifies the receiver of the functional group's data The 
value is registered by the same authority as the rece iver's <inter id qualifier>_value_definedJn.6.2.3.4.1.^ 

If the receiver is a bank (i.e. the <mterjd_qualrffer> in the ISA header is "17"), the application receiver 
ID shall be the bank's routing number. If the value of <interjd_qualifier> is other than 17, the value of 
this data element shall be as registered by that entity. 

Size: 02/15 
Type: AN 

<app_recelverjd> (02/15) ::= <string> 
Values: 9 digits long. 
Protocol support: Mandatory 
Business usage: Mandatory 

6.3.1 .1 .4. Functional group date 

The Functional Group Date <fg_date> specifies the creation date of this functional group. 
Size: 06/06 
Type: DT 

<fg_date> (06/06) : := <date> 

Values: YYMMDD where YY represents the year, MM represents the month, and DD represents the day: 
YY shall be 00 through 99; 
MM shall be 01 through 12; 
DD shall be 01 through 31. 

Protocol support Mandatory 
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6.3 Common data structure 

Each functional group defined in this standard is a structure consisting of Common X12 Elements, 
General Fit Extensions, and specific elements for that particular type of functional group. 

6.3.1. Common X12 structures 

All of the structures in this clause have the syntax specified in X12.22. if no values are specified herein, 
the values are as defined in X12.22. if the values herein differ from those in X 12.22, the values herein 
take precedence. 

63.1.1. GS functional group header 

The following Functional Group Header (GS) is used throughout this standard to identify the start of a set 
of transactions which share a common bond. Its syntax is defined in X12.22 and included here for 
reference. 



Table 13 - GS: Function header element names 



OS -Function Header 
element names 


Size 


Data 
type 


Ret 


Protocol 
support 


Business 
usage 


<fgjteader> 






GS 






<functionaLgroupJd> 


02/02 


AN 


470 


M 


M 


<app_senderjd> 


02/15 


AN 


142 


M 


M 


<ipp_f£C6tv6r_id> 


02/15 


AN 


124 


M 


M 


<fa_date> 


O6A06 


OT 


373 


M 


M 


<fo_t!me> 


0406 


TM 


337 


M 


M 


<function_oontrol_funnbef> 


01AS9 


N 


28 


M 


M 


<standard> 


01/02 


AN 


455 


M 


M 


<vefsion> 


01/12 


AN 


460 


M 


M 



The function header <fg_header> indicates the beginning of the functional group. It contains information 
which applies to the entire functional group, it shall be first in the functional group. 

6.3.1.1.1. Functional group ID 

The Functional Group ID <functionaLgroupJd> conveys a value containing the identity of the functional 
group. 

Size: 02/02 
Type: AN 

<*urtctional_group_lo>{02/D2) :^=<string>l - X9.46 registered values only 

<fuuncial_datsLgroup> I <tem_vtew8_group> I <app1icatton_8C*_group>l 
<quefy_requests_group> I <functiona1_ac<_group> I <private_types> 

<financiaLdata_group> ::= "70" 

<ftem_vlews_group> :r= "71" 

<application_ack_group> ::= "72" 

<quefy_request3_group> ::= "73" 

<functionaLacK^group> ::="FA" - Imported from X12 - 997 functionaJ acknowledgment 
<prfvate_types> "60" I ... I "99" 

Values: 

70" means Rnancial Data 

vr means Item Views 

*72 m means Application Acknowledgment 
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6.2.3.10 Subelement separator 

The Subelement Separator <subelement_separator> provides the capability to indicate a value for the 
subelement separator. This standard specifies it to be a certain value, as described in 6.1.5. 

Size: 01/01 

Type: AN 

<subelefnent_separator> (01/01) ::= <string>- data element 115 : X12.5 
Values: See <us> in clause 6.1 .5 for value. 
Protocol support: Mandatory 
Business usage: Mandatory 
6.2.4. X12IEA trailer 

The X12 1EA Trailer <inter_trailer> structure contains management and control information for an 
interchange. It shall always be last in an interchange. It is created by the originator of the interchange. All 
XI 2 IEA trailer fields shall have values, as required by X12.5, and specified in this clause and annex B of 
this standard. The following table specifies the data elements in an X12 IEA trailer. 



Table 12 - X12 IEA trailer element names 





X12 IEA trailer 


Size 


Data 


Ret. 


Protocol 


Business 






element luune 




type 




support 


usage 






<imerjrailer> 






IEA 










<numt>8r_groups> 


01/OS 


N 


116 


M 


M 






<inte r_control> - - ■ - 


- 03(09 


N 


112 


M 


M — ■ 





The X12 IEA trailer is defined in X12.22 and included here for reference. 
6.2.4.1 . Number of included functional groups 



The number of included functional groups <number_groups> is a count of functional groups contained in 
this interchange. The value is set by the creator of the interchange. 

Size: 01/05 

Type: N 

<number_groups> (01/05) ::= <numerio- data element 11$ : X12.5 
Protocol support Mandatory 
Business usage: Mandatory 
6.2.42. Interchange control 

The Interchange Control <inter_control> provides control for the interchange by conveying a unique 
identifier that names the interchange. It shall have the same value as <inter_control> in the associated 
X1 2 ISA header. 

The syntax and semantics are defined in 6.2.3.7. 

<inter_control> (09/09) ::= <numeric>~ data element 112 : X12.5 

Protocol support: Mandatory 

Business usage: Mandatory 
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6.2.3.7 Interchange control 

The Interchange Control <inter_control> is an originator-determined numeric value that is unique to this 
interchange, across all interchanges generated by the same originating institution. It shall be the same 
value as In the X12 IEA Trailer. 

When functional acknowledgments have been requested, the receiver of this interchange shall place this 
same value in the acknowledgment's appropriate segment Together with the sender ID, it uniquely 
identifies the interchange contents to an acknowledgment receiver. 

Size: 09/09 

Type: N 

<inter_control> (09/09) ::= <numerio- data element 112 : X12.5 

Values: Determined by sender. 
Protocol support: Mandatory 
Business usage: Mandatory 

6.2.3.8 Acknowledgment requested 

The Acknowledgment Requested <ack_requested> provides the capability to request a receiving Fll- 
translator to acknowledge that the interchange was received. 

X9 does not use this level of acknowledgment because it is not specific enough. Instead, this standard 
uses a Functional Acknowledgment and Application Acknowledgment mechanism to indicate reception of 
an interchange. 

~Siro:~ 01701 ~ ~~ — 

Type: ID 

<ackjequested> (01/01) ::= <dd>- data element 113 : X12.5 

Values: "0' shall be used. This indicates that this level of acknowledgment was NOT requested. 
Protocol support Mandatory 
Business usage: Mandatory 
6J&3.9 Test Indicator 

The Test Indicator <teaUndicator> provides the capability to indicate if this is a test interchange. It has 
usefulness during early stages of implementation of interchanges. 

Size: 01/01 

Type: ID 

<fesUndicator> (01 Art) ::= <$d>- data element 114 : X125 

Values: "P" means "production": and 
T means "tesf 

Any other value means test". 
Protocol support Mandatory 
Business usage: Mandatory 
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6.2.3.5.2 Interchange time 

The Interchange Time <inter_time> is a value which indicates the time the originator created the 
interchange. The value shall represent the originator's local time. 

Size: 04/04 
Type: TM 
Format- 
Values: HHMM where HH conveys the local hour, and MM conveys the local minutes: 

HH shall be 00 through 23; 

MM shall be 00 through 59. 
Protocol support: Mandatory 
Business usage: Mandatory 
6.2.3.6 Standard version 

The Standard Version <standard_version> conveys the Identity of the version of X12.5 being used in the 
subject Fit. It has two elements: standards identifier and version ID. 

<standard_version> ::= <standards_identifier>cgsxver$ion.id> 

<stan4ards_identifter> (01/01) :;= <id> - data element 110 : X1Z5 
<versionJd> (05/05) ::= <td> - value is 00305, data element 111: X12.5 

Protocol support: Mandatory 

.Busihess.usage: Mandatory 

6^3.6.1 Standards identifier 

The Standards Identifier <standard$ Jdentifier> indicates the EDI community creating the interchange 
standard. 

Size: 01/01 

Type: ID 

Values: Shall be "U a (US EDI Community). 
Protocol support Mandatory 
Business usage: Mandatory 
6.2.3.6.2 Version ID 

The Version ID <version id> conveys a value which indicates the version, as specified by XI 2.5 and 
X12.22. 

Size: 05/05 

Type: ID 

Values: ShaJl be '00305* to indicate the X12 Draft Standard for Trial Use Approved for Publication by 
ASN12 Procedures Review Board through December 1994. 

Protocol support Mandatory 

Business usage: Mandatory 
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6.2.3.4.1 Interchange ID qualifier 

The Interchange ID Qualifier <interjd_qualffier> is a value indicating the registry where the receiver ID 
value is registered. The syntax is defined in 6.2.3.3.1. 

Size: 02/02 

Type: ID 

Values: See 6.2.3.3.1 for values. 
Protocol support: Mandatory 
Business usage: Mandatory 

6.2.3.4.2 Receiver ID 

The Receiver ID <receiverjd> is a value assigned by the registrar which defines the receiver, tf 
interchange ID qualifier is "17", then the value is the bank's routing number. 

Size: 15/15 

Type: AN 

Values: Bank routing number, or the recipient's name if the value of the <lnterjd_qualffier> is other than 

■ir. 

Protocol support: Mandatory 
Business usage: Mandatory 
6.2.3.5 Interchange date and time 

~The-lntert*iange~Date-and-Time-drt — 
elements: Interchange Date and Interchange Time. For X9 purposes, the interchange date and time 
represent the local date and time of the originator. 

<iriter_date_tlme> :n= <inter_date> <gs> <inter_time> 

<Jnter_date><06/D6) ::= <date>- data element 108 : X12.5 

<inter_time><04/04) ::= <hourxminute>- data element 109 : X12.S 

Protocol support Mandatory 

Business usage: Mandatory 

6-2.3.5.1 Interchange date 

The Interchange Date <inter_date> Is a value indicating the originator's business date when the 
interchange was created. 

Size: 06/06 

Type: DT 

Values: YYMMDD where YY represents the year, MM represents the month, and DO represents the day: 

YY shall be 00 through 99 
MM shall be 01 through 12 
DO shall be 01 through 31 

Protocol support: Mandatory 

Business usage: Mandatory 
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<sender> ::= <interjd_qualifier> <gs> <sender_id> 

dnterjd_qualffier> (02/02) ::= <Id> - data element 105 : X12.5 
<senderjd> (15/15) ::= <string>- data element 106 : X125 



<interjd_qualrfier> (02/02) ::= <id> - data element 105 : X12.5 
Protocol support: Mandatory 
Business usage: Mandatory 
6.2.3.3.1 Interchange ID qualifier 



The Interchange ID Qualifier <interjd_qualrfier> is a value indicating the registry where the sender ID 
value is registered. 

Size: 02/02 

Type: ID 

Values: X12 registered values, 
dnter Jd_qualifier> (02/02) dd> - data element 105 : X12.5 

01 (per XI 2.22) indicates that the sender id value is a DUN's number (Dun and Bradstreet). 
17 (per XI 2.22) indicates that the Sender ID value is a routing number including a Check Digit 
(Thomson Bank Registry). 

Protocol support: Mandatory 

Business usage: Mandator y 

6^.3.3.2 Sender ID 

The Sender ID <senderjd> is a value assigned by the registrar which defines the sender. If interchange 
ID qualifier is "17", then the value is the bank's routing number. Other values are defined in X12.5 

Size: 15/15 

Type: AN 

Values: Bank routing number, or the originator's name if the value of the <inter_id_qualffier> is other 
than "17\ 

Protocol support Mandatory 

Business usage: Mandatory 

6.2.3.4 Receiver 

The Receiver <receiver> associated with the interchange has two elements: Interchange ID Qualifier and 



Receiver ID. 



<receiver> 



::= <InferJd_qualifier> <gs> <receiver_ld> 
<id> - data element 105 : X12.5 



«dnterjd_qualifier> (02/02) 

<*eceiverjd> (15/15) 
Protocol support Mandatory 
Business usage: Mandatory 



::= <sfring>- data element 107 : X12.5 
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Values: Shall be W indicating that no meaningful information is in ISA header field I02, i.e., No 
authorization information present . 

Protocol support: Mandatory 

Business usage: Mandatory 

6.2-3.1.2 Authorization information 

The Authorization Information authorization Jnfo> is a value which defines the authorization. 

Size: 10/10 

Type: AN 

Values: All zeros 

Protocol support: Mandatory 

Business usage: Mandatory 

6.2.3.2 Security 

The Security <security> associated with the interchange has two elements: security qualifier and security 
Information. 

<securtty> ::= <security_qua!tfler> <gs> <securityJnfo> 

<security__quatifier> (02/02) ::= <id> - data element 103 : X12.5 
<securttyJnfo> (10/10) ::= <string>- data dement 104 : X12.5 

Protocol support Mandatory 0 

B usiness usa g e: Mandator y 

6.2.3.2.1 Security qualifier 

The security qualifier <securtty_qualtfier> is a value indicating the meaning of the security information. 
Size: 02/02 
Type: ID 

Values: Shall be W indicating that no meaningful information is in ISA header field 104, i.e., No 
security Information present . 

Protocol support Mandatory 

Business usage: Mandatory 

6.2.3.Z2 Security information 

The security information <securfty Jnfo> is a value which defines the security information. 

Size: 10/10 

Type: AN 

Values: All zeros. 

Protocol support: Mandatory 

Business usage: Mandatory 

6.2.3.3 Sender 

The Sender <sender> associated with the interchange has two elements: interchange ID qualifier and 
sender ID. 
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Table 11 - X12 ISA header element names 



ISA header field 
element names 


Size 


Data 
type 


Ref 


Protocol 
support 


Business 
usage 


<imer_headar> 




_ 


ISA 


__ 


. 


<Buthorization> 








_ 




<authorizalk>n„qualtfier> 


02/02 


ID 


101 


M 


M 


<authorizationjnfo> 


10/10 


AN 


102 


M 


M 


<$&curttv> 












<security_quaJrfier> 


02/02 


ID 


103 


M 


M 


<securityjnfb> 


10/10 


AN 


104 


M 


M 


<sender> 












<inter Jd_q ualifie r> 


02/02 


ID 


105 


M 


M 


<sender_td> 


15/15 


AN 


(06 


M 


M 














<nter_ld_quaJifier> 


02/02 


ID 


105 


M 


M 




15/15 


AN 


107 


M 


M 


<inter_date_ time> 












<inter_date> 


06AJ6 


DT 


108 


M 


M 


<imer_thne> 


04AM 


7M 


109 


M 


M 


<standard_version> 












<standartfsjdentifier> 


01/01 


(D 


110 


M 


M 


<version_Jd> 


08/05 


to 


111 


M 


M 


<irtter_oontrot> 


09/09 


N 


112 


M 


M 


"<ack_requested> 


01/01 


ID 


113 


M 


M 


<test_indicator> 


01/01 


ID 


114 


M 


M 


<subeIement_separator> 


01/01 


AN 


115 


M 


M 



The following definitions of the elements and subelements comprising the ISA header are defined in 
X 12.22, and are included for reference. Unlike other subelements, the ISA subelements always are 
separated using the <gs> separator character. Each element that has an X12 reference is separated with 
a data element separator (<gs>). 

6.2-3.1 Authorization 

This is the Authorization <authorization> associated with the interchange. It has two elements: 
<authorization_qualifier> and outhorization Jnfo>. 

<authortzation> ::= <authorfzation_qualffier> <gs> outhorization Jnfo> 

<authorization_qualifler> (02/02) ::s <ld>- data element 101 : X12.5 
<auttiorizationJnfo> (10/10) ::= <strfng>- data element 102 : X12.5 

Protocol support: Mandatory 

Business usage: Mandatory 

6.2.3.1 .1 Authorization qualifier 

The Authorization Qualifier <authorizatk>n_quatifier> is a value indicating the meaning of the 
authorization information. 

Size: 02/02 

Type: ID 
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Zero or more Query Requests functional groups may be present in each interchange. Additionally, this 
functional group provides a mechanism to restart a search at a specific reference point The restart 
mechanism enables the originator to limit 1) the range of possible results, and 2) the likelihood of run- 
away search requests. 

Protocol support: Optional. 

Business usage: Conditional, shall be present if a Query Requests Functional Group is present in the 
interchange 

6.2.2.7 Interchange trailer 

The Interchange Trailer <inter_traifer> contains the management and control information for the 
interchange. It shall be last in the interchange, and is paired with an X12 ISA Header. Its syntax is 
specified in 6.2.4. 

Protocol support Mandatory 

Business usage: Mandatory 

6.2.3 X12 ISA header 

Ihe XI 2 ISA Header <lnterjteader> contains the management and control information for an 
interchange. It always is first in an interchange. There is only one in each interchange. It is created by the 
originator of the interchange. All X12 ISA Header data elements shall have values, as required by X12.5 
and specified in this clause and annex D of this standard. 
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Protocol support: Optional. 

Business usage: Conditional, shall be present if views of imaged items are in the interchange. 
6.2-2.4 Functional acknowledgment functional group 

The Functional Acknowledgment functional group <functional_ack_fg> contains the requested 
acknowledgment information for a functional group, transaction set, or data segment, as illustrated in 
figure 10. It shall be used by a receiving Fll-translator to report the results of a syntax level check of the 
interchange. This standard utilizes the X12 Functional Acknowledgment (FA) to provide the requested 
positive, or negative, syntactic acknowledgment 

Zero or more Functional Acknowledgment functional groups may be present in each interchange. 

Unlike the X12 EDI definition, this standard defines a mechanism in the general Fll extensions for 
requesting X12 functional Acknowledgment. Thus, it shall only be generated in response to a request by 
the originator of the subject Fll. 

Protocol support: Optional. 

Business usage: Conditional, shall be present if a Functional Acknowledgement is conveyed in the 
interchange. 

6.2^5 Application acknowledgment functional group 

The Application Acknowledgment functional group <application_acH_fg> contains the requested 
acknowledgment information for a functional group, transaction set, or data segment level, as illustrated in 
figure 11. It conveys the receiving Fll-system-user application's acceptance or rejection of the 
interchange, or its components, after evaluating the semantics of the contents of the interchange. 

Zero or more Application Acknowledgment functional groups may be present in each interchange. An 
Application Acknowledgment shall only be generated in response to a request by the originator of the 
subject Fll. 

Protocol support: Optional. 

Business usage: Conditional, shall be present if an application acknowledgement is conveyed in the 
interchange 

6^2.6 Query requests functional group 

The Query Requests functional group <query_requests_fg> contains requests for views of imaged 
items, information associated with a view, imaged Hem, and groupings of imaged items, as well as 
requests to cancel outstanding queries. The structure shall be as illustrated in figure 12. 

The Query Requests functional group supports the following functions: 

- Retrieve based on specific key(s), or image item names, 

- Retrieve based on general search criteria, and 

- Cancel a "not yet completed" query request 

- Cancel a previously sent Financial Data, or item Views transmission, or portion thereof. 
A Fll-system-user also may specify the desired query operation results: 

- Retrieve the actual images (or portions of an imaged item), item data, or privately understood 
data, for the imaged items found matching several ranges of selection criteria such as amount, 
serial numbers, etc., 

- The transport medium to be used to return the data found meeting the search and retrieve 
selection criteria, and 

- whether the results should be secured (signed, or MAC'd) 
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Table 10- Financial image interchange structure 



Rl structure 


Size 


Data 


Ret 


Protocol 


Business 






type 




support 


usage 


<fii_8tructure> 












<nter_header> 






ISA 


M 


M 


<fioancial_(Jata_fq> 








o 


B4 


«dtem_viaws_fg> 








0 


B5 


<functional_ack„fg> 








0 


B6 


<appfication„acJ(Jn> 








o 


B7 


<query_request_fn> 








o 


B8 


<tnter_traiter> 






[EA 


M 


M 



The Fll structure <fii_structure> consists of the following edi structures: 
6.2.2.1 Interchange header 

The Interchange header <lnter_header> contains information needed to manage and control the 
interchange. It shall be first in the interchange. 

Protocol support: Mandatory 
Business usage: Mandatory 
6 2 2.2 Financial data functional group 

The Financial Data functional group <financial_data_fg> contains electronic check exchange data. Zero 
or more financial data functional groups may be present in each interchange. For example, this functional 
group may contain one or more transaction sets, where each transaction set may contain a financial data 
segment that conveys a X9.37 file. The structure shall be as illustrated in figure 8. The syntax can be 
found in 6.4.1. 

Protocol support: Optional. 

Business usage: Conditional, shall be present if financial data is in the Interchange. 
6.2 2.3 Item views functional group 

The Item Views functional group <item_vtews Jg> contains views of items and processing information 
associated with a view, imaged item, and groupings of imaged items. The structure shall be as illustrated 
in figure 9. The syntax can be found in 6.4.2. 

In the context of a query response, its contents comprise: 

- One or more views of a single imaged item; 

- One or more views of multiple imaged Hems; 

- Item information about one or more imaged items (e.g., image keys, or compression indicators); 

- User data only about one or more imaged items. 

In the context of forward or return processing, its contents may contain: 

- Some, all, or none of the images associated with a cash letter, 

One or multiple subgroup(s) of images, not associated with any ECE cash letter. 
Zero or more Item Views functional groups may be present in each interchange. 
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Query Requests 
Fnt Group 




Figure 12 * Query requests functional group model 



It contains one or more Query Request Transaction Sets within the functional group , and optional 
security related features as follows: 

Query Requests Functional Group: 

Functional Group Header . 

Functional Group Security Header 

Signature Transaction Set 

Query Request Transaction Set 

Functional Group Security Trailer 

Functional Group Trailer 

Each Query Request Transaction Set shall have one General FII Extension segment, and one or more 
query request data segments: 



Query Request Transaction Set: 
Transaction Set Header 
Transaction Security Header 
Signature Data 
Signature 

General FII Extensions 
Query Request data segment(s) 
User Data segment 
Transaction Security Trailer 
Transaction Set Trailer 



6,2.2. Top level FII structure 



Table 10 describes the top level Financial Image Interchange structure. When different types of functional 
groups are present in a single Fll t they shall appear in the order indicated in table 10. Each FII 
conformant interchange shall contain at least one type of Functional Group defined in this standard. 
Functional groups of the same type may appear in any order. 
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Figure 11 - Application acknowledgment functional group model 

It contains one or more Application Acknowledgment transaction sets within the functional group as 
follows: 



Application Acknowledgment Functional Group: 
Functional Group Header 
Functional Group Security Header 
Signature Transaction Set 
Application Acknowledgment Transaction Set(s) 
Functional Group Security Trailer 
Functional Group Trailer 

Each Application Acknowledgment transaction set is provided for conveying verification that responsibility 
for the received Fll is accepted (or not) by the receiving Fll-system-user. Its structure is as follows: 

Application Acknowledgment Transaction Set 
Transaction Set Header 
Transaction Security Header 
Signature Data Segment 
Signature Binary Segment 
General Fll Extensions Data Segment 
Acknowledgment Data Segment(s) 
Transaction Set Security Trailer 
Transaction Set Trailer 



6.2.1.5. Query requests functional group 



A Query Requests functional group is provided for conveying requests for imaged items, corresponding 
item information, and optionally, privately agreed user data as illustrated in figure 12. 
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Figure 10 * Functional acknowledgment functional group model 



It contains one or more Functional Acknowledgment transaction $et(s) as follows: 

Functional Acknowledgment Functional Group: 
Functional Group Header 
Functional Acknowledgment Transaction Set(s) 
Functional Group Trailer 

Each Functional Acknowledgment transaction set (a.lea. the X12 997 transaction set) is provided for 
conveying verification that the received Fll is syntactically correct It shall contain one Transaction Set 
Header and one Transaction Set Trailer, and one or more Functional Acknowledgment data segments): 

Functional Acknowledgment Transaction Set 
Transaction Set Header 

Functional Acknowledgment Data Segments), i.e., X12 segment identifiers AK1-AK9 
Transaction Set Trailer 

6.2,1.4. Application acknowledgment functional group 

An Application Acknowledgment functional group Is provided for conveying verification that the received 
Fll is accepted by the receiving Fll-systenvuser. It is illustrated in figure 1 1 . 
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For each group of related bundles of imaged items, each instance of Item Subgroup shall contain one 
Item Subgroup data segment and one or more sets of item data: 

Item Subgroup Segment: 

Loop Header (top level) 

Item Subgroup Information Segment 
ltem(s) Data Structure 

Loop Trailer (top level) 

For each imaged item in a bundle of related imaged items, each instance of item data shall contain one 
hem Information segment and one or more item views: 

Item Data Loop: 

Loop Header (middle level) 

Item Information Segment 

Signature Data Segment 

Signature Binary Segment 

User Data Segment 

Item View(s) Structure 

Loop Trailer (middle level) 

For each view of an imaged Hem, each instance of Hem view shall contain one item view data segment 
and one view binary data: 

Item View Loop: 

Loop Header (bottom level) 

Item View Segment 

View Binary Data Segment 

Loop Trailer (bottom level) 

6.2.1 .3. Functional acknowledgment functional group 

A Functional Acknowledgment functional group is provided for conveying verification that the received Fll 
is syntactically correct, as illustrated in figure 10. 
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Figure 9 - Item views functional group model 

An Item Views functional group is defined to convey information about items, user-defined data, views of 
imaged items, contained in one, or more, Item Group transaction set, and optional security-related 
features as illustrated in figure 9 as follows: 



Item Views Functional Group: 
Functional Group Header 
Functional Group Security Header 
Signature Transaction Set 
Item Group Transaction Set(s) 
Functional Group Security Trailer 
Functional Group Trailer 



An Item Group transaction set shall contain one general Fll extension data segment, and one or more 
hern subgroup structures which contains image items that are organized into groups of related 
(conceptual) bundles of imaged items: 



Item Group Transaction Set: 
Transaction Set Header 
General Fll Extensions Data Segment 
Item Subgroup Segment(s) 
Transaction Set Trailer 
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Figure 8 - Financial data functional group model 



As illustrated in figure 8, the Financial Data functional group is composed as follows: 

Financial Data Functional Group: 
Functional Group Header 
Functional Group Security Header 
Signature Transaction Set 
Financial Data Transaction Set(s) 
Functional Group Security Trailer 
Functional Group Trailer 

Each Financial Data transaction set contains one General Fll Extension segment and one Financial Data 
segment 

Financial Data Transaction Set 
Transaction Set Header 
General Fll Extensions 
Financial Data (Binary) Segment 
Transaction Set Trailer 

6.2.1.2. Item views functional group 

The Item Views functional group has more hierarchical layers than the other functional groups. It 
comprises transaction sets (where each contains groups of related imaged items), subgroups, item data, 
and item views as illustrated in figure 9. This design mimics the cash letter structure as currently used in 
the banking community. As such, the functional group structure can be viewed as corresponding to cash 
letters, bundles of Items, detail items, and multiple views of each imaged item. 
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a transaction set reveals that it is composed of lesser objects called Segments. This standard uses 
several kinds of segments: Loop Header and Trailer segments, Data segments, and Binary segments. 
The concept of the existence of this lesser object is defined in X12.5. The functional groups comprise the 
main information objects exchanged in the Fll protocol. Multiple functional groups of different types may 
be present in the same interchange, but they shall appear in the order specified in 6.2.2. 

A functional group is the collection of related information objects exchanged between financial institutions. 
The collection of Fll functional groups, and related transaction sets, can be graphically illustrated as in 
figure 7. 




Figure 7 - FU functional group structure 

The financial data regarding this transaction, and the supporting digitized image information, are 
conveyed as a set of sub-objects. The digitized image-related information is carried in a detail segment, 
deeply nested in a series of loops inside the Item Group transaction set. The loops mimic the financial 
industry's cash letter data structure used in cash letter processing . This design also provides a 
mechanism for cross-referencing between transaction sets and detail segments, and between transaction 
sets in the same interchange, or across interchanges. Additionally, security mechanisms are provided at 
all levels within a functional group for the purposes of data integrity, confidentiality, non-repudiation, and 
authentication. Further explanation and illustration, are provided in 6.2.1.1 through 6.2.1.4 and annex F of 
this Standard. 

6.2.1.1. Financial data functional group 

A Financial Data functional group is intended for conveying MICR line information and associated check 
processing data. As indicated elsewhere in this standard, the syntax of the processing data is outside of 
the scope of this standard. However, to facilitate the exchange of this type of data, this functional group 
contains a Financial Data transaction set and optional security related features, as illustrated in figure 8. 
In this and the next figures, a label in a box names an X12 defined label, and a label outside of a box 
names an X9.46 defined label. 
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Figure 6 - FII structure 



The FII structure consists of an ISA Header and an IEA trailer which surround one, or more, functional 
groups of digitized information. As defined in X12, an interchange is formed by sequencing components 
into a stream of bytes for exchange between applications. It can be illustrated as follows; 

Interchange header (ISA) 

Functional group 1 
Functional group 2 



Functional group n 
Interchange trailer (IEA) 

The functional groups comprise the primary information objects exchanged through the FII protocol. 
Multiple functional groups of different types may be present in the interchange. Annex A and 622 
specifies their order of appearance in an interchange when multiple types of functional groups are present 
In a single interchange. The five types of functional groups specified In this Standard are as follows: 

- Financial Data functional group (<financlaLdataJg>); 

- Item Views functional group f</fem_ views_ fg>); 

- Functional Acknowledgment functional group (<functionaLack^fg>); 

- Application Acknowledgment functional group (<appl_ackjfg>); 

- Query Requests functional group (<query_requests_fg>). 

The FII structure (<fti_6tructure>) utilizes the X12 EDI model and protocol, i.e., the model specified in 
X12.5. However, this standard extends the X12 model to define synchronously interactive query services 
and protocols, and to specify an Fll-system-user acknowledgment (at the application level) that may 
convey the user's acceptance (or rejection) of an interchange, and partial results to query requests. This 
standard also defines a data segment that extends the X12 transaction set header, and provides a 
mechanism for including digital signatures in the interchange. 

6.2.1 . Functional group overview 

Functional decomposition of a functional group reveals that It Is composed of lesser objects called a 
functional group header, transaction sets (TS), and a functional group trailer. Functional decomposition of 
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a. 77?ere shall be at least one element in a segment (in addition to the segment identifier). Data 
elements composed of subelements whose values are defined to be Optional still must 
contain the subelement separator, if any subelement value is present 

b. If elements are defined as optional or defaulted, it is necessary to retain the <gs> or <us> 
delimiter as required to avoid ambiguity. For example, if a segment would normally appear 
as 

"SEG <gs>a<gs>txgs>c<gs>d<gs>e<tr>" 

and the values b,c, and e are the default values for those positions, then the segment could 
also be comprised as 

"SEG <gs>a<gsxgs><gs>d<gsxtr> 91 

or as 

"SEG <gs>a<gsxgsxgs>d<tr>" 

(note that the last <gs>, that is immediately followed by a <tr>, is optional since it is not 
required to prevent ambiguity). 

Similarly, an element encoded as 

"v<us>w<us>x<us>y<us>z" 

with w, x, andz defauhable, can be comprised as 

"v<usxusxus>y<us>" 

or as 

u v<usxusxus>y" 

6.1 .8 Bit organization for any pixel byte 

For bit organization and bit padding, see annex B. 

SJ2. FII structure and specification of data elements 

From a modeling perspective, the FII can be viewed as comprising numerous information objects. The 
primary object is the interchange itself. Functional decomposition reveals that it comprises lesser objects: 
a single ISA header; one, or more, functional groups; and a single IEA trailer. This standard specifies four 
(4) functional groups, and imports one acknowledgment functional group directly from X 12.22 (i.e., a 
"Functional Acknowledgment"). When present in the interchange, functional groups shall appear in a 
specific order, as illustrated, left to right, in figure 6. 

In the following figures, shadowed boxes indicate that the object may occur multiple times 
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6.1 .5 Segments, elements, subelements, and delimiters 

Structures in X12 are composed of building blocks called segments. There are two types of segments: 
control segments and data segments. Control segments are used to define headers and trailers for 
such structures as interchanges, functional groups, transaction sets, and loops. Data segments are used 
to define objects such as cash letters, checks, and images which are recognizable in a business context. 

Segments are composed of elements, which are sometimes, in turn, composed of subelements. A 
segment may be defined as a sequence of elements separated by data element separator characters 
and terminated with a terminator character. An element may be defined as either a single data instance 
of a type specified in section 6.1.4, or as a sequence of such data instances which are separated by 
subelement separator characters. 

The separators and terminator characters are defined in table 9. Note that this standard, unlike the X12 
standard, requires that the delimiters take only the value listed in table 9. Because delimiters are used to 
aid fn disassembling the interchange, the listed values shall not be used within any data type, except 
within a BIN segment which is ignored when parsing the interchange structure. 



Table 9 - Separators and terminator characters 



Separator names: 
Delimiters used In this standard 


Code 


Notation 


ASCII/ 
EBCDIC 
Decimal 


ASCII/ 
EBC01C 
HEX 


Data element separator 


<QS> 


GS* 


29 


1D 


Sub-element separator 


<us> 


US* 


31 


1F 


Terminator (ends a FG/TS/DS) 


<tr> 




28 


1C 



1 GS means group separator as defined in 3.1 of X12.5 

2 US means unit separator as defined in 3.1 of X12.5 

3 FS means file separator as defined in 3.1 of X12.5 



Within a segment, the semantics of a data instance is dependent on its position. The first data instance is 
always a two or three character segment identifier. This identifier names the segment which, in turn, 
identifies the syntax and semantics of its remaining data instances. As an example, the identifier, "ISA", 
represents an interchange header, its syntax and semantics are described in section 6.2.3. The length of 
a segment is the number of bytes from the beginning of the first element (i.e., including the segment 
Identifier) through (and including) the terminator character. 

Within an element, the meaning of a data instance dependents on its position. However, rather than 
including an element identifier, the syntax and semantics are defined by the position of the element within 
the segment The length of an element is the number of bytes from the beginning of the first subelement 
through the end of the last subelement Subelement separator are included in the length calculations. 



6.1.6X9.46 delimiters 

The embedded V character delimits variable length component values within a data element 

6.1.7 Intra-segment syntax Intra-segment syntax for the segments defined in section 6.15 is governed 
by the following:: 
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6.1. 4 5 Decimal Number 

A decimal number type identifies a numeric data element which contains an explicit decimal point and is 
used for numeric values that have a varying number of decimal positions. The representation for this data 
element type is R. The decimal point always appears in the character stream, if the decimal point is at 
any place other than the right end. If the value is an integer (decimal point at the right end), the decimal 
point should be omitted. For negative values, the leading minus sign (-) is used. Absence of the sign 
indicates a positive value. The plus sign (+) should not be transmitted. Leading zeros should be 
suppressed unless necessary to satisfy a minimum length requirement. Trailing zeros after the decimal 
point should be suppressed, unless necessary to indicate precision. The use of a triad separator (for 
example, the commas in 1,000,000) is expressly prohibited. The length of a decimal type does not 
include the optional leading sign. 

This standard's specific additional requirements for a decimal number syntax are as follows: 

• If the value is an integer (decimal point at the right end), the decimal point shall be omitted. 

• Leading zeros shall be suppressed unless, necessary to satisfy a minimum length requirement 

• There must always be at least one digit before an embedded decimal point. 

• Trailing zeros after the decimal pant shall be suppressed, unless necessary to indicate 
precision. 

• The representation for this data element type is <decimat> in annex A 

• The length of the decimal number does not Include the optional sign or decimal point, for 
example the value 2.3 or J23 has a length of 2, and that 2.33, 233 or 23.3 has a length of 3. 



6.1.4.6 Binary 

The binary data element is a syntax which is composed of any sequence of bytes (8 bit encoding), each 
ranging in value from binary 00000000 to binary 11111111. This data element has no defined maximum 
length. Actual length of any binary encoded object is specified in bytes by the immediately preceding 
data element. The representation for this data element type is B v and <binary> in annex A. X12 uses the 
term binary data because a translator conforming to the standard has no specific understanding of this 
sequence of bytes . Normally, a receiving Fll-translator will make its value available to the receiving Fll- 
system-user, without regard to its integrity or correctness. This Is a consequence of the value's (i.e., the 
encoded object) syntax and semantics being outside the scope of this standard. 

6.1.4.7 Identifier 

An identifier data element always contains a value from a pre-defined list of values that is maintained by 
the X12 Committee, or some other body recognized by the X12 Committee. Trailing spaces should be 
suppressed unless necessary to satisfy minimum length. The representation for this data element is ID. 

This standard's specific additional requirements for an identifier syntax are as follows: 

• This data element is composed of a sequence of characters from: the set of upper case letters A 
to Z, digits from 0 to 9, and the space character. 

• The representation for this data element is <id> in annex A 



27 



COPYRIGHT American National StandArda Institute 
Licensed by Information Handling Services 



XP008074623 



X9.46-1997 

This standard's specific additional requirements for a time syntax are as follows: 

• The value for time shall be expressed in terms of the originator's local time zone. 

• The character repertoire Is composed of the digits 0 through 9. 

• Data values shall be populated left to right 

• Representation for this data element type is <time> in annex A. 

If the size of a data element (whose data type is TM) is constrained to a length of 4, then the value is in 
hours and minutes (HHMM). If It is constrained to a length of 6, then the value is in hours, minutes, and 
seconds {HHMMSSS}, and so on. 

A decimal point separating SS and d..d is implied, i.e., an embedded decimal point is not used in this 
syntax. 

6.1.4.3. String 

A string syntax identifies a value which is composed of a sequence of any characters from the basic or 
extended character sets. Space filled data elements apply to fixed length data values. The significant 
characters shall be left justified, and shall be space filled. Leading spaces, when they occur, are 
presumed to be significant characters. Trailing spaces should be suppressed unless they are necessary 
to satisfy a minimum length. The representation for this data element type is AN. 

This standard's specific additional requirements for a string syntax are as follows: 

• These characters are also classified as 'printable' or alpha-numeric 

• The representation for this type is <string> in annex A. 



6.1 AA Numeric 

A numeric is represented by one or more positive digits with an optional leading sign representing the 
value in the normal base of 10. The value of a numeric data element includes an impOed decimal point 
Elements representing dollar amounts have an implied decimal of 2, i.e., they convey values in cents. It is 
used when the position of the decimal point within the data is permanently fixed, and is not transmitted 
with the data. The data element dictionary defines the number of implied decimal positions. The 
representation for this data element type is Nn, where "N" indicates that it is numeric and "n" indicates the 
number of decimal positions to the right of the implied decimal point If *n" is 0, it need not appear in the 
specification; a N' is equivalent to "NO*. For negative values, the leading minus sign (-) is used. Absence of 
the sign indicates a positive value. The plus sign (+) should not be transmitted. Leading zeros should be 
suppressed unless necessary to satisfy a minimum length requirement The length of a numeric type data 
element does not include the optional sign. 

This standard's specific additional requirements for a numeric syntax are as follows: 

• It is composed of one or more positive digits from the set 0 through 9 and whose encoding is 
specified in 6.1.3. 

• All values shall be positive fie., a minus symbol is not used). 

• The representation for this type is <numerio in annex A. 
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b. Other special characters 



Table 7- Other special characters 



uescnpnon 


Character 


ASCII 


AC/MI 

ASCII 


EBCDIC 


EBCDIC 






decimal 


hex 


decimal 


hex 


percent sign 


% 


37 


25 


108 


6C 


less than sign 


< 


60 


3C 


76 


4C 


greater than sign 


> 


62 


3E 


110 


6E 


commercial at 




64 


40 


124 


78 


opening bracket 


t 


91 


5B 






reverse solid us 


\ 


92 


5C 


224 


E0 


closing bracket 


] 


93 


5D 


— 




underscore 




95 


5F 


108 


en 


Anon inn smiHv Kra^o 


T 


123 


7B 




*7R 
/D 


pipe (vertical bar) 




124 


7C 


173 


AD 


closing curly brace 


) 


125 


7D 


208 


DO 


tilde 




126 


7E 


161 


A1 


National characters 














Table 8 - National characters 






Description 


Character 


ASCII 


ASCII 


EBCDIC 


EBCDIC 






decimal 


hex 


decimal 


hex 


number sign 


# 


35 


23 


123 


7B 


dollar sign 


$ 


36 


24 


91 


5F 



6.1.4 Data type representations 

The following data types are used throughout this standard to Identify the character repertoire, or 
encoding, used in a data element (i.e., element) or subelement: 

6.1.4.1 Date 

The date identifies the syntax expressing the ISO standard date in YYMMDD format in which YY is the 
year within the century (00 to 99), MM is the month (01 to 12), and DD is the day (01 to 31). 
Representation for this data element type is DT. 

This standard's specific additional requirements for a date syntax are as follows: 

• The character repertoire is composed of the digits 0 through 9. 

• Representation for this data element type is <date> in annex A 

• The value for date shall be expressed in terms of the originator's local date. 

6.1.4.2 Time 

The time syntax identifies a value expressing the ISO standard time in HHMMSSd..d format in which HH 
is the hour for a 24 hour clock (00 to 23), MM is the minute (00 to 59), SS Is the second (00 to 59). and 
d..d is the decimal second. Representation for this data element type is TM in the tables and <time> in 
annex A. 
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c Special characters 



Table 5 * Special characters 



Description 


Character 


ASCtl 


ASCII 


EBCDIC 


EBCDIC 






decimal 


hex 


decimal 


hex 


exclamation point 


! 


33 


21 


90 


5A 


quotation mark 


■ 


34 


22 


127 


7F 


ampersand 


& 


38 


26 


80 


50 


apostrophe 


• 


39 


27 


125 


7D 


opening parenthesis 


( 


40 


28 


77 


40 


closing parenthesis 


) 


41 


29 


93 


50 


asterisk 


* 


42 


2A 


92 


5C 


plus sign 




43 


2B 


78 


4E 


comma 


* 


44 


2C 


107 


6B 


hyphen (minus sign) 




45 


2D 


96 


60 


period 




46 


2E 


75 


4B 


solidus 


/ 


47 


2F 


97 


61 


colon 




56 


3A 


122 


7A 


semicolon 




59 


3B 


94 


5E 


equals sign 


B 


61 


30 


126 


7E 


question mark 


? 


63 


3F 


111 


6F 



d. Other characters 



Table 6 • Other characters 



Description 


Character 


ASCII 


ASCII 


EBCOIC 


EBCDIC 






decimal 


hex 


decimal 


hex 


space character 


oi 


32 


20 


64 


40 



1 - The symbol ■ 0 ■ is used only for editorial purposes to represent a space character whose encoding is 
as indicated in the table. 

6/1.3.2. Extended character set 

The extended character set may be used, if not prohibited in the Banking Practices Agreement It includes 
the lowercase letters and other special characters specified below: 

a. Lowercase /offers from a to z 

(ASCII: 97 to 122 decimal; €1 to 7 A hex. respectively) 

(EBCDIC: 129 to 136, 145 to 153, 162 to 169 decimal: 81 to 69, 91 to 99, A1toA9 hex, 
respectively) 
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B32 shall be present when a snippet is requested. 

B33 shall be present to obsolete an outstanding query request. 

B34 shall be present to override the 300 second default. 

B35 shall be present only to request a generic search on a specific value or range of 
values. 

6.1.3 Character set 

All data element and subelement values, except those of a binary data element, shall be created using 
characters and symbols specified in 6.1.3.1 or 6.1.3.2. Tliese are subsets of ASCII and EBCDIC 
character sets. Unless otherwise stated in the Banking Practices Agreement, all characters and symbols 
shall have representation in the common character 8-bit ASCII code scheme, which Is based on CCITT 
V.3 International Alphabet 5. Optionally, characters may also be encoded in 8-bit EBCDIC rules, if 
permitted in the Banking Practices Agreement ASCII and EBCDIC characters shall not be intermixed in 
the same interchange. ASCII encoded characters are always encoded beginning with the most significant 
(left-most) bit, and ending with the least significant (right-most) bit 

6.1.3*1 Basic character set 

The basic character set shall be composed of the following characters: 

a. Uppercase tetters from AtoZ 

(ASCII: 65 to 90 decimal; 41toSA hex, respectively) 

(EBCDIC: 193 to 201 ,208 to 217, and 226 to 233 decimal; C1 toC9,D1to D9, andE2toE9 
hex; respectively) ' _ ~ * ~ ~ 

b. Digits from 0to9 

(ASCII: 48 to 57 decimal; 30 to 39 hex, respectively) 
(EBCDIC: 240 to 249 decimal; FO to F9 hex, respectively) 
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Bu shall be present if the data element is required. 

B« shall be present if an acknowledgement is requested, and the defaults are 
inappropriate. 

B13 shall be present when responding to query request, may be present for other 
transaction sets. 

B 14 shall be present for transaction sets containing item group, financial data, or query 
requests. 

B 15 shall be present only to redirect an acknowledgement to a recipient other than the 
sender of this functional group. 

Bie shall be present when responding to a Query Request 

Bi 7 shall be present only to specify a limit for a generic criterion. 

Bib shall be present when <general_fiLextensions> are conveyed in the Financial 
Data Functional Group. 

B 19 shall be present when <gerteraLffi_extension$> are conveyed in the Item Group 
Transaction Set 

B20 shall be present only in an Item Group Transaction Set 

B21 shall be present in Item Views Functional Group unless explicitly omitted in Banking 
Practices Agreement - ... . . 

622 shall be present to cross reference to financial data, or query requests, if 
appropriate. 

B23 shall be present when cross referencing to another X9.46 transaction set, unless 
explicitly omitted by the Banking Practices Agreement 

B24 shall be present only to supplement the routing number of the financial institution by, 
or through whom, the item is payable. 

B2s shall be present if necessary to identify property the snippet 

B26 shall be present when <ctippingJnfo> are conveyed. 

B27 shall be present only if <application_ack_diagnostic_code> indicates that 
constraints have been exceeded unless explicitly omitted in the Banking Practices 
Agreement 

B28 shall be present if the <query_request_type> is other than a cancel request ("0"). 

B29 shall be present if the <query_request_type> is cancel request fXT) or restart 
request ("3°). 

B30 shall be present only if specified in BPA, and then shall be subject to the type of 
acknowledgment requested.. 

Ba, shad be present If the <query_request_type> is retrieve request CO- 
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C 19 valid only ff both snippet origin and offset are used. 
Czo valid only if snippet origin is used. 

C21 valid for any transaction set, shall be present when responding to a query request 

C22 valid only when the acknowledgement is in response to a query request other than 
Query Cancel Request ("0"). 



Only elements designated OPTIONAL may identify a DEFAULT value. A DEFAULT shall indicate 
that, if the value for the element is absent in an Fll. a receiving Fll-translator shall understand It to 
convey the semantics of the value designated as DEFAULT in this standard. Receiving Fll- 
translators, or Fll-system-users, shall not consider the absence of any Optional, or DEFAULTed, 
element of protocol to be a protocol violation. If two structures or elements may be either both be 
present or not present, the first element (such as header) is designated as OPTIONAL and the 
second, such as a trailer, is designated CONDITIONAL 

The fact that a minimum length is specified for values, does not prevent Optional (or 
DEFAULTed) values from being entirely absent from an interchange with an actual length of zero. 
This descriptive convention is used to be consistent with X12 standards. 

f. Business usage 

This column contains values indicating the support required of business user applications by this 
standard. Its value expands upon the protocol support as required by the business community. 
The values shall be one of the following: 

ill Mandatory: The value(s) for this data structure, data element value, or subeiement value 
shall be present upon ongination of the interchange, and shall be handled and made 
available to the receiving Fltsystem-useron reception. Business usage is always mandatory 
when protocol support is mandatory. 

B x Business Conditional: A value for this data element or subeiement is present, or absent, 
under certain conditions, or as defined in the Banking Practices Agreement Specific 
predicates are indicated with numbers (i.e. Bx) defined in the inline text. Use of a Default 
value satisfies a Business Conditional usage requirement 

B t shall be present only if specified in Banking Practices Agreement 

B2 shall be present unless explicitly omitted in the Banking Practices Agreement 

B3 shall be present only to override or supplement Banking Practices Agreement 

B 4 shall be present if financial data is in the interchange. 

Bs shall be present If views of imaged items are in the interchange. 

Be shall be present If a Functional Acknowledgement is conveyed in the interchange. 

B7 shall be present if an application acknowledgement is conveyed in the interchange. 

Be shall be present if a Query Requests Functional Group is present in the interchange. 

Bg shall be present only to specify or to convey security features or security 
mechanisms. 

B 10 shall be present if the <query_request_type> is restart request ("3"). 
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If not present, no error will be generated because of the absence of an optional data 
structure (functional group, transaction set, data segment), data element orsubelement 

Cx Conditional: The Fit-translator's origination Support for this data structure, data element, or 
subeiement is mandatory under certain conditions, and optional under all other conditions. 

The predicates V are indicated with numbers (i.e. Cx) defined as follows: 

C t shall be supported if security at the present structural level is supported. 

C2 Conditional, valid only when the value of <trans_setjd> in the Transaction Set header 
is Item Group, Financial Data, or Query Request 

C3 required when cross referencing between transaction sets. 

C4 each shall be supported, but only one shall be present in acknowledgement 

C 5 ff Query Requests Functional Group is supported, it too shall be supported. 
However, it shall only be present in a cancel request ("0"), and no other data 
elements shall be included in the segment 

Cg shall be present only if signature data <signature_data> is present 

C7 present only If requested to be acknowledged at the this level. If used, either the 
<subject_ts_ref Jd>, <subject_tsd_ref Jd>, <subject_jtem_refjd>. 
<sub]ecUtem_yiewJd>, or <su b|ect_qrd_id> , shall be present. The presence of 
more than one of these shall be considered a protocol violation. 

The term valid is used in the predicates C a - C23 to indicate that the applicability of a 
specific data element depends on the type of structure and function. It does not dictate the 
presence of the value in the interchange, and the data element is considered to be optional. 

Cs valid only if the <query_request_type> is other than a cancel request f0°) 

C9 valid only in a Financial Data Functional Group 

C10 valid only In a Item Group Transaction Set 

t valid only if required by or applicable to the security mechanism utilized. 

C t2 valid only if the <query_request_type> is cancel request f 0")or restart request 

m 

C 13 valid only if the <query_request_type> is search request ("2"). 

C14 valid only if the <query_request_type> is retrieve request ("1"). 

C 15 valid only when <view_side_requested> is frontal view CO") or rear view ("1"). 

Ci6 valid only if the <query_request_type> is restart request 

C 17 valid only if <application_ack__diagnostic_code> indicates that constraints have 
been exceeded ("8"). 

C 18 valid only If snippets are used. 
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c. Data type 

This column shall contain values which represent the kind of data required for the entry. The 
values shall be date (DT), time (TM), string (AN), numeric (Nn), decimal number (R), binary (B), 
or Identifier (ID). The meaning of these values is described in 6.1 .4 through 6.1 .9. 

The ID type requires that the values be registered in X12.22. 

d. Reference 

This column contains the appropriate reference for any data element specified in X12.5, X12.6, 
X12.22, and X12.58 version 003050 and structures defined in this standard. The reference is to 
the X12 data dictionary number or label. For example, rf the table defines the X12 ISA header, 
this reference is to the X12.5 data element definitions. A structure enclosed in brackets d ]) is 
defined by X9.46. 

e. Protocol support 

This column contains values indicating the support required by this standard, and X12, for these 
entries. Support shall be verified as part of an implementation's conformance evaluation. The 
values shall be one of the following: 

M Mandatory: 

On origination of the interchange, this data structure (functional group, transaction set, data 
segment), data elements value, or subetemenfs value; shall be present, and shall comply 
with As defined syntax, i.e., size and data type as specified. An error shall be generated if this 
data structure (functional group, transaction set, data segment), data element, orsubelement, is 
absent. 

On reception of the interchange, this data structure (functional group, transaction set, data 
segment), data element, orsubelement, shall be handled and made available to the receiving 
Fll-system-user. An error shall be generated if this data structure (functional group, transaction 
set, data segment), data element, orsubelement, b absent 

- 'Handle 0 means that the Fll-translator will recognize ft correctly parse its syntax, 
and validate only its size and data type. 

- 'Make Available' means that the Fll-translator will pass the data contents to the 
Fll-system-user. 

An optional data-element may contain optional or mandatory subelements. If a subelement 
is mandatory it shall be present when the parent data element is present 

O Optional: 

On origination, this data structure (functional group, transaction set, data segment), data 
element, or subelement may be supported by the translator . When supported, it shall have 
a size and data type as specified 

On reception, Fll-translator shall support this data structure (functional group, transaction set, 
data segment), data element, or subelement as follows: 

If present this data structure (functional group, transaction set, data segment), data 
element or subelement shall be handled by the receiving Fll-translator and shall be 
made available to the receiving Fll-system-user. 
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6.1 -2 Element table conventions 

The element tables used throughout this standard summarize the structures, data elements, and data 
subetements. Each table uses the following layout and conventions: 



Table 4 - Element table conventions 



Data Element Names 


Size 


Data 
type 


Re* 2 


Protocol 
support 


Business 
usage 


<structure_name> 












<elemefH_name> 1 












<subordinale_etemenL.name> 












<8ubelemenL.name> 













1 - The <etement_name> may also be a structure name 

2 • X9.46 referenced components are shown in brackets ([ D. white X12 referenced components lack brackets. 

All loops in this standard should not exceed 999999 iterations, unless otherwise specified in this 
standard. 



A dash (-) in any column of the table indicates that column is not applicable for that specific data element 
The column titles indicate the following information: 

a. Data element names 

This column contains the structure, data element, and data subelement names that . are Ao be 
used for each entry. The names are surrounded by o to match the BNF coding notation used in 
annex A. Successively lower levels are indented. A <subordinate_etement_name> in itafics Is 
present to Identify a parent data element which is included for Information only. It has no identity 
in the protocol, except through its associated subelements, i.e.. <subelement_name>. 



b. Size 

This column shall define the minimum and maximum number of characters of the value for a data 
element when present The format is XXIYY where XX is minimum size, and YY is maximum 
size. Values outside of the range shall be considered protocol violation. If the data element is 
composed of subelements, the s'rze includes the sub-element separator characters. The data 
element delimiter (<gs>) and structure delimiter (<tr>) are not included in the size value. 

The size for subelement values does not include the subelement separator. However, 
subelement delimiters are included in the size of the parent data element because subelement 
separators) shall be present in a data element even though the value for the subelement may be 
absent For example, when the data element consists of 3 sub-elements, the size value for XX 
and YY will be determined as the value, plus 2 characters for the 2 sub-element delimiters. 

The size of a structure is the sum of the following components: 

- 1 character for each data element delimiter, plus, 

- 1 character for the structure terminator (<tr>), plus, 

- 2 or 3 characters for the length of the structure identifier (e.g., a GS fl = 2 characters), 
plus, 

- Sum of the sizes of the values for the actual data elements. 
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6.1 .1 Interchange structure template 

Each clause that defines a functional group, transaction set, or data segment will be specified using the 
following template: 



• Name; 

• Description including: 

- Purpose; 

- Number of occurrences; 

- Position in the interchange hierarchy. 

• Protocol support; 

• Business usage; 

• Table of elements in structure. 



Each data element and sub-element will be defined with the following (see 3.2. 6.1.1.1 ..and 6.1.2 for 
more explanation): 



Name; 

Description including: 

- Source; 

- Examples. 
Size; 

Data type (alpha-numeric, numeric, decimal, etc.); 

BNF notation 

Values; 

Protocol support; 
Business usage. 



6.1.1.1 Values 



Values for X9 defined data elements and X12 specified data elements shall be only those defined in this 
version of the standard. Values which are reserved in this standard for private use may be used per the 
Banking Practices Agreement. Any value that is not reserved or defined in this standard shall not be used, 
as its presence may cause rejection of the interchange by a receiving application, or may be used in 
future versions of this standard. Future versions of this standard may assign a different meaning to that 
value. 



Some element values have been defined as the concatenation of values from other data elements without 
the use of the subelement separator. When concatenated without the subelement separator, the value of 
the element is populated left to right, as specified in the description for the (concatenated) element. 

The term DEFAULT has been applied to certain data element values throughout this specification. When 
used in the data element's definition, the value, identified with the key word DEFAULT, shall be 
understood and used, by the receiving Fll-transiator when an actual value for that data element is absent 
from the interchange. If an actual value is present in the interchange for a DEFAULTS data element, the 
value that Is present takes precedence over the DEFAULT. DEFAULTS provide a mechanism for reducing 
the size of an interchange. 

NOTE - The fact that a minimum length is specified for values does not prevent Optional (or DEFAULTed) 
values from being entirely absent from an interchange with an actual length of zero. This descriptive convention 
is used to be consistent with X12 standards. 
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Standardized exchange 



Figure 5 - Function of an Fll Translator of the receiving application 
5.1.5 Transfer Mechanism 

A Transfer Mechanism specifies how packaged interchange content is delivered from the originating 
imaging application's Fll-transiator to the receiving imaging application's Fll-translator. Examples of such 
a method are: 

• Through physical delivery of a computer medium which contains the packaged interchange data. 

• Through a computer network by transmitting the packaged interchange data electronically. 

The specifics of the Transfer Mechanism are outside of this Financial Image Interchange Standard, but 
are within the purview of a Banking Practices Agreement. 



6 Hi technical specification 

This clause specifies the Financial Image Interchange (Fll), including data structures and protocol that are 
used for the conveyance of the data in accordance with the Fll Model illustrated in annex F. The Fll 
Model, illustrated in figure F.3 employs a hierarchical order when specifying the names, contents and 
definitions of the X12 ISA header, X12 IEA trailer, functional groups, transaction header sets, and data 
segments. 

This standard is wholly based on the principles and transaction interchange formats as defined in the X12 
EDI specification. However, it goes well beyond the current capabilities of the X12 EDI model by 
introducing query and acknowledgment translator services for Fll-system-users. 

6.1 Conventions, character sets, and data types 

The following clauses specify the notation conventions, character sets, and data types used throughout 
this specification. 
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sequential series of steps, diagrammed as a switch, which emits and accepts standardized interchange. 
The standardized interchange is the standard structure that is exchanged across system boundaries. 

In the examples of the originating and receiving applications in figures 4 and 5, the Functional Groups are 
all of one type, and could be any one of the data groups defined herein. 

The Fit-translator's functional model, i.e., the behavior of the translator, and the emitted (and accepted) 
protocol are covered in this Standard, and further elaborated in annex D of this standard. The translator is 
modeled as having 2 interfaces: one well specified interface which emits and receives Flls, and a "fuzzy" 
interface that passes data to and from the user application. Some times this standard places 
requirements on actions that occur across the fuzzy interface that may be implemented by either the user 
application, the translator, or by some private means. However, the internal design of a Fll-transiator is 
not part of this standard. 

NOTE - A FH-translator may be implemented as part of imaging applications, to enable imaging applications to 
deposit the data groups Into, or withdraw them from, the interchange data structure. 



Application 



Originating 



Oata 





Bank's environment 



The standardized exchange 



Figure 4 - Function of an Fll Translator of the originating application 
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Figure 3 - Interchange data structure 

The transaction set contents are different for each functional group. 

For example, the structures contained in the Fll's functional groups are as follows: 

For a Financial Data functional group, the transaction set contents contain financial data; 

For an Item Views functional group, the transaction set contents contain bundles of views of 
imaged Items, Item information for each view and item view data; 

For a Query Requests functional group, the transaction set contents contain query request data; 

For an Application Acknowledgment functional group, the transaction set contents contain 
acknowledgment data. 

For a Functional Acknowledgment functional group, the transaction set contents contain syntax 
analysis results data. 

Security header, security trailer, and other security data are handled by mechanisms outside of, and 
beyond, this specification, but are accommodated by this standard. 

5,1.4 Translator 

The translator (Fll-translator) function of the originating application produces an interchange object (i.e., a 
complex data structure) by translating the output of the local image handling, data processing, or data 
storage application into a standardized interchangeable "edi" structure. The peer translator function of the 
receiving application translates the *edi" interchange Into the locally understood data structures for 
subsequent storage or processing of the data by the receiver's application. The functions of the Fll- 
translator are shown in figures 4 and 5. 

Figure 4 and 5 show examples of a translator processing multiple functional groups of imaged items on 
behalf of originating (Figure 4) and receiving (Rgure 5) imaging applications. The translator follows a 



14 



COPYRIGHT American national Standards Institute 
Licensed by Information Handling Services 



XP008074623 



X9.46-1997 

The kinds of data supported in this standard are as follows: 

• Financial item processing data which relate to a physical financial item; 

• Digitized representations of an item, and its corresponding image processing data; 

• Query request data for requesting information about stored imaged Hems, or for requesting the 
images themselves; 

• Receiver acknowledgment data to signal acceptance (or rejection) of an interchange , as well as 
a listing of the names of imaged items found that meet a set of query selection criteria. 

The functional groups which correspond to the four kinds of data mentioned above are the following: 

• Financial data 

• Item Views 

• Functional Acknowledgment 

• Application Acknowledgment 

• Query Requests 

More than one Functional Group may be included in an interchange. An interchange may contain a mix 
of functional group types. 

In the current environment of paper check exchange, a cash letter analogy can be applied to the design of 
the Financial Data, and Item Views functional groups: 



Table 3 - Paper exchange and its FU-structure counterpart 



Paper exchange 


HI structure counterpart 


Electronic cash letters 


Financial data segment 


Groups of physical cash 
letters 


Item views functional group 


Physical cash letters 


Item views functional group 


Physical kill bundles 


Item subgroup 


Physical items 


Item information and views 



5.1 .3 Data structure 

Figure 3 shows the genera) organization of interchange data structures within an X12 EDI interchange. 
The contents between the header and the trailer consist of one, or more, groupings of data which are 
functionally related, called a functional group. A functional group contains a group header, a group trailer, 
and group contents. The group contents consists of sets of related transaction data, called transaction 
sets, and optionally, a group security header and trailer. Transaction sets consist of related data 
organized in the form of segments, called data segments. Data segments are made up of a segment 
identifier, data elements, and delimiters. 

The term structure is used throughout this document for simplicity to identify Functional Groups, 
Transaction Sets, and Data Segments. 

The details of a functional group's content can be found in clause 6. 
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This standard describes the data (the letter contents) and the interchange, consisting of the envelope and 
Its contents (data). In this standard, the Financial Image Interchange (Fll) is the instance of an electronic 
data interchange (edi) defined in this standard. 



Interchango 



Originating 
Imaging 
Application 


Data ^ 


Originating 




translator 



Transfer 
Mechanism 



Receiving 
translator 



Data 



Receiving 
Imaging 
Application 



Figure 2 - An abstract representation of the Fll system's model 

An abstract representation of the financial image interchange system's model is shown in figure 2. This 
model represents the end-to-end Interchange process, from the originating imaging application to the 
receiving imaging application. In the model, data to be interchanged may consist of any combination of 
the following: financial data, item groups (image view data), acknowledgments, or query requests. There 
may be many Fll-translators that operate on the contents of an interchange as it moves to its final 
destination. The data to be interchanged from the originating imaging application are packaged by the Fll* 
translator, and sent to the receiving imaging application. Upon receipt of the Interchanged data, the Fll- 
transtator will unpackage (parse) the incoming data for the receiving imaging application. Then, the 
receiving imaging application may generate acknowledgments or replies to query requests, and become 
the originating imaging application for a new image interchange. 

The image interchange system terms corresponding to those in figures 1 and 2 are listed as in table 2: 



Table 2 • Relationship between Fll terms 



Fll terms 


Figure 1 terms 


Figure 2 terms 


Fll-systenvuser (application) 


The originating person 


The originating imaging application 


User data 


Letter 


Data 


Fll -translator (originator) 


Deposit the letter Into the envelope 


Originating translator 


Fll structure 


Addressed envelope with contents (data) 


Interchange structure 


Transfer mechanism 


Post office mail delivery 


Transfer mechanism 


Rt-transtator (receiver) 


Withdraw the letter from the envelope 


Receiving translator 


Fll-system-user (application) 


The receiving person reads the letter 


The receJvtng Imaging application uses the 
data 



This analogy is used only as an aid In explaining the use of a standardized interchange, and is not 
intended to be an implementation directive. 

5.1*2 Data 

The originator of an interchange has the purpose of providing data, and the receiver of an interchange 
has the intent to do work from the data received in an interchange. 

Using the analogy described in figure 1 , the data to be interchanged corresponds to the contents of the 
envelope. Inside the envelope, there may be several letters and each tetter may have several pages and 
paragraphs. Indeed, several tetters may be sent In the context of this standard, each letter can be 
viewed as a functional group, consisting of data, which is defined to perform a similar function. 
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5. Technical overview 



5.1 Introduction 



This overview provides a high level description of the financial image interchange process, the structure 
of the image and the image related data, and the use of data structure in the interchange process. This 
standard provides for end-to-end exchange, query, and acknowledgment of financial data and images. It 
does this by presenting a system model and a description of its protocol components: data, data structure, 
translator, and internal procedures. 

This standard specifies the data groups and data structure for financial image interchange. In addition to 
interchanging images, this standard also supports interchanging financial data, acknowledgment, and 
query request services associated with images and financial data. It does this by defining expected 
procedures to be followed to complete an end-to-end exchange of information, so that translators achieve 
a common minimum level of service. The creation and use of the data by the originating and receiving 
imaging applications at the communicating financial institutions are outside the scope of this standard. 
The process of how to deposit the data into, and withdraw them from, the data structure and the method 
employed to deliver the data structure containing the deposited data (communication method) are outside 
the scope of this standard. 

This standard also defines the conditions for which a financial image interchange translator is deemed 
compliant on origination and reception. 

Clause 5 introduces the concepts for Financial Image Interchange. Clause 6 and Annex A provide the 
detail specification, and clause 7 provides the conformance requirements. 

5.1.1 System model overview 



An analogy of a person sending a letter to another person may be used to explain how an image 
interchange system works. Figure 1 shows two persons involved in the letter communication process. 
One Is the originating person, and the other is the receiving person. The originating person writes a letter, 
puts it into an envelope, and drops the envelope into a post office mail box. The post office takes the 
envelope and delivers it to the receiving person. The receiving person opens the envelope, withdraws the 
letter from it, and reads the letter. 



The letter 



The letter 




The ocfglnatlnQ 
person who 
writes a tetter 



Deposits the letter 
Into the envelope 



Fostofftoetfefiveiy 



Removes the letter 
from the envelope 



The rooeMng 



reads the letter 



Figure 1 • An analogy of a person sending a letter to another person 

An imaging interchange system is similar to the preceding analogy. As illustrated in figure 2, in an imaging 
interchange system, there is an originating imaging application and a receiving imaging application. The 
originating application produces data, deposits the data into a data structure, and sends it by some kind of 
transfer mechanism . The receiving imaging application withdraws the data structure to obtain and 
process the data. The process of depositing data into, or withdrawing data from, a data structure is 
accomplished by the (financial image interchange) translator. 
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4.2.4 Rnancial data considerations 

The following clauses address considerations for financial data. 

4.2.4.1 Sending financial data with Images 

The images and financial data may be sent together, or separately. However, the financial data (i.e., 
electronic check exchange data) should be sent in a separate interchange from its associated images. 
This is recommended primarily because of the importance of the financial data. Because of the relatively 
large size of interchanges containing images, the processing of interchanges containing both financial 
data and imaged items may impact adversely the processing time for financial data. 

4.2.4.2 Correlation of imaged Hems to financial data 

Rnancial data shall contain sufficient information to correlate to the imaged items. If using an X9.37 
format, the components of an image key can be created from elements of an ECE Bundle record , 
together with components of the ECE Check Detail record . This is possible only if the institution creating 
the image is the same as the ECE institution, and the ECE bundles are not broken anywhere prior to 
receipt by the payor. Therefore, this standard assumes that an intermediary never breaks an ECE bundle. 

• The institution creating the image also must have the financial data available to create properly an 
image key. This is true even If the Institution creating the image is not the same as the ECE 
institution. 

• The institution creating the image shall use financial data to create the image key, even if it uses a 
different: 

Sequence number for the image from that of the ECE Item Sequence Number, or 
Date for the image from that of the ECE Business Date. 

In the event it uses a different sequence number, or date, it shall maintain an internal cross-reference 
to access the image, if needed. The payor bank remains unaffected. 

If the Institution creating the image uses other procedures, the correlation between the image and the 
financial data is subject to agreements between the parties. If the correlation between an image and its 
corresponding financial data is not possible, the payor may use the right of refusal to ask for the paper, or 
for other arrangements, as stipulated in its Banking Practices Agreement. 

4.2.5 Query request considerations 

When originating a query request, users should observe the following: 

• Multiple requests for the same institution may be sent in the same interchange; 

• When an acknowledgment has been requested, a negative acknowledgment is used to indicate 
that a request failed; 

4.2.6 Acknowledgment considerations 

Application Acknowledgments resulting from the receiving Fll-system-user's failure to accept a Functional 
Group or a Transaction Set shall always be sent, unless otherwise indicated. The user may expressly 
request that all Application Acknowledgment types not be sent 

Requested Functional Acknowledgment shall be generated before any Application Acknowledgment is 
generated, and Application Acknowledgment shall be generated before any response to a query request 
is generated. 
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4.2 Summary of business considerations 

This clause includes business considerations addressing recommended procedures and practices 
designed to assist in implementation. 

4.2.1 EPC tt 9 D authorization 

Only the payor bank shall authorize its customer to use checks printed with a "9° in the EPC field of the 
MICR line. The presence of the "9° in the EPC field of the MICR line designates a check as a candidate 
for subsequent image interchange with or without item truncation. 

4.2.2 Banking practices agreement 

Participants in financial image interchange shall establish a Banking Practices Agreement (BPA). This 
agreement provides a formal basis for interchange between institutions. 

To assist in understanding Banking Practices Agreements, annex C covers the following: 

1) Description of a suggested framework for interchange covering presentment and settlement 
terms, storage and availability of images, and returns, drawing on existing regulations; 

2) A pro forma Banking Practices Agreement formalizing this framework; and 

3) A description of other business, or technical considerations, such as communications method, 
media used in the interchange, acceptable compression algorithms and imaging parameter 
options, ASCII or EBCDIC encoding, and image requirements. 

4JZJ3 imaging considerations 

The following points address considerations for imaging of items: 
4.2L3.1 Images and associated electronic check data 

The interchange of check images shall always be predicated upon the financial data. The financial data 
shall precede, or accompany, the image (and its corresponding item information). The financial data could 
have arrived hours, days, or even years earlier. 

4.2.3.2 Image capture 

The institution participating in check image interchange shall capture both the full front and the full back of 
the item. 

4.2.3.3 Image, front and back 

The institution participating in check image interchange shall provide the ability to interchange the full 
front or the full back of the item, or both, in accordance with the Banking Practices Agreement 

4.2.3.4 Accepting images 

Payor institutions should accept "usable" images provided according to prior Banking Practices 
Agreements (see annex C). The payor institution shall have the right to refuse an image, a group of 
images, or an entire image interchange, if deemed unusable, and request the physical items(s). 
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4.1 .4 Acknowledgments 

This standard defines mechanisms for sending and receiving two classes of acknowledgments. One class 
of acknowledgment advises whether, or not, the syntax of the interchange, or portion of an interchange, is 
correct The other class advises whether, or not, the contents of an interchange, or portion of an 
interchange, is correct. 

For detail specification, please see 6.4.3. 

4.1.5 Retrievals 

This standard defines mechanisms for carrying sufficient information with an image view, or views, to 
support the retrieval of individual views (e.g. front only, back only), partial views or snippets (e.g. 
signature, endorsement), and multiple views (e.g. front and back, front, back, and signature). 

4.1.6 Cross-referencing images 

Cross-referencing mechanisms are provided at two levels in this standard: 

• Cross-referencing an imaged item with its associated detail financial data; 

The tool for this level is the image key, which accompanies an imaged item as part of the item 
information. The image key shall be constructed from components of the financial data. 

• Cross-referencing components of an interchange with other components of the same interchange, 
or with components of other interchanges; 

The tool for this level is a set of cross-reference data elements. For example, mechanisms are 
provided tor crossrreferencing between queries and responses, or between an entire financial data 
interchange and an imaged item interchange. 

4.1 .7 Compression algorithm support 

Compression of views of items included in an interchange shall use one or more of the following 
algorithms, and associated parameter options, in accordance with Banking Practices Agreements. For 
details on supported compression algorithms, please see annex B. 



Table 1 - Compression algorithms and parameter options 



Compression algorithm 


Spatial scan 
density* (DPI) 


Number of gray 
levels 


Uncompressed 


80-240' 


2,4,16,64,256 


CCITTT.6 


200-240 


2 


ISO JPEG Baseline 
(1 component) 


100-200 


256 


JBIG Baseline, D=0 


60-240' 


2,16 


ABIC 


80-240' 


2,16 



NOTES - 

1 . BWevel (2 levels) shall have a spatial scan density greater than or equal to 200 DPI. 

2. "DPP is the number of dots per inch. 
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4.1.1 Financial data 

This standard defines mechanisms for sending and receiving financial data, such as an entire ECE. The 
financial data format is specified in formats such as those defined by X9.37, ECCHO, the Federal 
Reserve, or the Banking Practices Agreement. For detail specification, see 6.4.1 . - 

4.1.2 Digitized images and associated data 

This standard defines mechanisms to exchange a digitized image (or images) of an item, or portions of a 
digitized image, with associated data. The exchanging of images and data may support forward or return 
processing, or the response to a query request. It may comprise a single item, or a bundle of items. A 
bundle of items relates to an associated ECE bundle, or just a set of items sent together. A group of 
bundles relates to an associated ECE cash tetter, or just a set of bundles sent together. 

• Items: For each item, e.g. check, this standard defines mechanisms for sending and receiving 
both information about the item (item Information) and digitized representations of the item. Item 
information includes such things as the amount of the Hem, payor bank routing number, and cross 
reference to the financial data, i.e., image key. Digitized representations of the item include such 
things as the item's front or back, portions of an image view, or multiples of each. 

• Bundles of Items: For each bundle of items, the standard defines a mechanism for providing 
control information, such as amount of bundle, end-point, and number of items in the bundle. 

• Groups of Bundles: For each group of bundles, the standard defines a mechanism for providing 
control information similar to that for bundles of items. 

For detailed specification, please see 6.4.2. 



4.1.3 Query requests 

This standard defines mechanisms for sending and receiving query requests. The user application may 
request item information, views of an item, or both, for one or more imaged items. Several different Query 
Requests functions are supported: 

• "Retrieve by specific key" requests that the receiver (i.e., a user application) return images, item 
information, or both, for the items identified by an image key, or list of image keys. 

• "General search" requests that the receiver return images or item information, or both, for the items 
which meet all of a set of criteria. The selection criteria may include criteria such as: 

- Business Date, or range 

- Sequence Number, or range 

- Cycle Number, or range 

- Amount, or range 

- Account Number, or range 

- Check Serial Number, or range 

- ECE Routing Number 

• "Cancel" requests that the receiver cancel aspects of a previously sent interchange which contained 
financial data, digitized representations of items, or query request(s). 

• "Restart* requests that the receiver restarts a previous query request which had been terminated 
because some of the specified constraints were exceeded. 

For detail specification, please see 6.4.4. 
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Fit ( Financial Image Interchange) 

Fll-system-user 

Fll-translator 

FHS (Financial Image 

FHP (Financial Image 



Object 
Octet 



ODA (ISO/lECs Open document 

Orientation Standard) 

Page 



3.2. Protocol syntax 

The following syntax conventions are applied throughout this standard: 

a. The Backus Naur Form (BNF) syntax is used to specify the Fll data structures, data elements, 
and subeiement protocol components. See 6. 1.5 for additional details. 

• Syntactic entities, i.e., data elements, are denoted by lowercase strings enclosed in angle 
brackets '<label>* in accordance with X12.6. 

• The defined construct on the left side of a statement is separated from the defining rig/to state 
by two colons and an equal sign That is, the statement on the right of *::=' defines the 
value of the data element named on the left side of 

• A vertical bar T indicates an "or condition, or alternative definition in accordance with 



• Braces "Q m enclose an item which may appear zero or more times In accordance with X12.6. 

• Square brackets m U B enclose optional items in accordance with X12.6. 

• Parenthesis m ( )' identity the size range. The size of the element does not includes the 
element delimiters. If the element is defined to have sub-elements, the size of the element 
does include the subeiement delimiters. 

The construct '(xx/yy) * identifies the lower and upper limits of the size range. The size 
occurs immediately after the <iabel> 

b. Data element BNF names appear in bold when used in in-line text. 

a For more definitive information see X12.6. 

The syntax used in Annex A is generally of the form: 

<labei> ::= <other labeb> I <sequence of labels> I <data typo I "value" 
4 Summary of standard 

This clause summarizes the functions of the standard and business considerations critical to a successful 
implementation of the standard. 

A technical overview appears in clause 5. which introduces the detailed specification contained in clause 
6, and is supported by annexes A, B and C. Annex J contains a glossary of terms used throughout this 
standard. A technical guideline (ANSI/ABA TG15-199x) supports implementation procedures and 
provides additional overview and explanation. 

4.1 Summary of functions 

The Financial Image Interchange standard defines the structure for sending and receiving of the 
following: financial data; digitized images with associated data; query requests; and acknowledgments. It 
also covers the retrieval of views, cross referencing of images to electronic check exchange (ECE) data, 
cross referencing within an interchange, and between interchanges, and compression algorithm support. 



X12.6. 
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[23] X1 2S 91 -690 - 1 9 91 : Introduction to Electronic Data Interchange 5 . 
(24] X12,5 -1994; Interchange Control Structure (release 003050) 5 . 
[25] X12.6 -1994; Application Control Structure (release 003050) 5 . 
[26] X12.58 - 1 994: Security Stmctures (release 003050) s . 



3. Definitions, terms, and conventions 

This section contains terms and definitions used throughout this specification for the purpose of this 
standard and takes precedence over normal use. 

3.1 . General terms 



The following terms used in this Standard are included in the glossary, annex J of this specification 



Adaptive Bilevel Image 


Financial data 


Partial view 


Compression (ABIC) 


Financial institution 


Pel (picture element) 


Bitonal 


Grays-scale 


Pixel (picture element or pel) 


Byte (Octet) 


Group 4 (T.6) 


Port 


Authentication 


Huffman coding 


Protocol 


ccrrr 


IOCA 


Repudiation 


Character repertoire 


Image (digital image) 


Resolution 


Character set 


Image capture 


Run-length encoding 


Character string 


Item views 


Sampling resolution 


Check processing data — 


— Image Key 


Scaling 


CIPS 


Image raster data 


Scan line 


Clipping 


Image processing 


Services 


Continuous tone 


Integrity 


Snippet 


Compression 


Interchange 


Spatial scan density 


Compression algorithms 


Interchange format 


Supplier 


Communication protocol 


Interchange protocol 


Text 


Confidentiality 


Interchange structure 


Thresholding 


Consumer 


Interoperate 


TIFF (Tagged image file format) 


Copy 


Item 


Transaction 


Cropping 


Item views 


Transaction Set 


Data stream 


ITU-T (International 


Transcoding 


Decompression 


Telecommunications Union 


Translator 


Default 


Telecommunications 


Truncation 


Dots per inch (DPI) 


Standards Sector) 


View 


ECCHO 


JBIG 


View parameters 


ECE (Electronic check exchange) 


JPEG 


View processing data 


ECE institution 


Local time 


Workflow 


EDI (Electronic Data Interchange) 


Lossless compression 


Zone 


edi (non-X12 conferment EDI) 


Lossy compression 




Envelope 


Media 




Facsimile 


Message 





X12 Standards may be purchased from OlSA. 1B0O Diagonal Road. Alexandria, VA 22314 Tel. ♦ 1 (888) 363-2334. X12 web 
address: http-J/www.cfisa-org. 
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[9] CCITT Recommendation X.402 (1988), Data Communication Networks - Message Handling 
Systems: Overall Architecture 2 . 

ISO/JEC 10021*1 Standard: Information Processing Systems - Text Communication - Message 
Oriented Text Interchange System - Part 2: Overall Architecture 3 . 

2JZ rrU-T/CCITT only standards 

{10] CCITT T.6 (Group 4) - International Telecommunication Union - CCITT - The International 
Telegraph and Telephone Consultative Committee Blue Book - Vol. VII - Fascicle VII.3 - 
Terminal Equipment and Protocols for Telematic Services - Geneva 1989, pp 48-56, ISBN 92- 
61-03611-2 2 . 

23 ISO/1EC only standards 

[1 1 ] ISO/1EC 7372: 1 986 - Trade Data Interchange - Trade Data Dictionary 

[1 2] ISO/IEC 9735:1 987 - Electronic Data Interchange for Administration, Commerce, and Transport 
(EDIFACT) - Application Level Syntax Rules 3 . 

[13] ISO/IEC 1 1 166-1 - Banking - key management by means of asymmetric algorithms - Part 1: 
Principles, procedures, and formats 3 . 

[1 4] ISO/IEC 9796 • 1991- Information Technology- Security Techniques - Digital Signature Scheme 
Giving Message Recovery 

2.4 -ANSI standards and technical guidelines — — 

[15] X3.92 (1992) Data Encryption Algorithm 3 . 

[1 6] X9.7 - 1 988: Bank Check Background And Numerical Convenience Amount Ftetd 4 . 

[17] X9.9 - 1 994: Financial Institution Message Authentication (Wholesale) 4 . 

[18] X9.13- 1990: Specifications for placement and location of MICR printing 4 . 

[1 9] X9.17 • 1 995: Financial Institution Key Management (Wholesale) 4 . 

[20] X9.30 - 1 995: Public key cryptography using irreversible algorithms for the FmancialSenrices 
industry Part 1: The DSA Signature Algorithm 4 . 

[21] X9.37 - 1 994: Specifications for Electronic Check Exchange 4 . 

[22] X9/TG-15-199x: X9.15 - 1995: Financial Image Interchange: Technical Guideline [Draft] 4 . 



4 X9 financial Industry standards can be ordered from: X9 Order Desk, cto ABA Customer Service Center. 1120 Connecticut 

Ave.. K.W, Washington. DC 20038. USA. Tel. +1 (800) 338 082B or ♦ 1 (202) G63-50S7. Fax +1 (202) 663-7543. X9 Online 
address: hnp://www Jt9.org/fc9. 
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2.1 Paired ISO/IEC standards and VTU-T/CCITT recommendations. 

[1 1 CCITT Rec. X.208(1 988): Abstract Syntax Notation - One 2 

ISO/IEC 8824: Specification of Abstract Syntax Notation One (ASN 1) 3 . 

[2] CCITT Rec, X.407(1 988): MHS: Abstract Service Definition Conventions 2 
ISO/IEC 1 0021 -3:1 990: MOTIS: Abstract Service Definition Conventions 3 . 

[3] CCITT Rec. T.41 1 -T.41 9 (1 988): Office Document Architecture 2 . 

ISO/IEC 8613:1989; Office Document Architecture 5 . 

[4] CCITT Rec. T.82 (1 993) Coded Representation of Picture and Audio Information - Progressive 
Bi-Leve! Image Compression 2 . 

ISO/IEC 11544, Coded Representation of Picture and Audio Information - Progressive Bi-Level 
Image Compression 3 . 

[5] CCITT Recommendation T.81 (1 992), Information Technology - Digital Compression and 
Coding of Continuous-Tone Still Images, Requirements and Guidelines 2 . 

ISO/IEC 10918-1 : 1 993, Information Technology • Digital Compression and Coding of 
Continuous-Tone Still Images, Part I: Requirements and Guidelines 3 . 

Z[6]ZZCCITT-Recommendation-T.83 (1 994), Intormatito 

Coding of Continuous-Tone Still Images - Compliance Testing 2 . 

ISO/IEC 1 091 8-2: 1 994, [DIS] - Information Technology - Digital Compression and Coding of 
Continuous-Tone Still Images, Part 2: Compliance Testing 3 . 

[7] CCITT Draft Recommendation T.84 (1 994), information Technology - Digital Compression and 
Coding of Continuous-Tone Still Images - Extensions 2 . 

ISO/IEC 1 0918-3: 1 994, [DIS] - Information Technology - Digital Compression and Coding of 
Continuous-Tone Still images, Part 3: Extensions?. 

[8] CCITT Recommendation XJ2D8 (1986) Data Communications Networks - Open Systems 
Interconnection (OSI) - Model and Notation - Service Definition - Specification of Abstract 
Syntax Notation One (ASN. 1) 2 . 

ISO 6624 Standard (1987, Information Processing Systems - Open Systems Interconnection - 
Specification of Abstract Syntax Notation One (ASN 1) 3 . 



CCTTT and fTU recommendations can be oniered from: American National Standards Institute. 11 West 42nd Street, New York. 
NY 10038, USA, telephone: +1 212 642 4300, tax 1 212 398 0023. ANSI Online address rmp^/www^nsLotg. 

ISO/lECand X3 standards can be ordered from: AmertcanNaUonal Standards Institute, 11 West 42nd Street, New York, NY 
10036, USA. telephone: +1 212 642 4900. fax 1 212 338 0023. ANSI OnQne address: rtttp^/www^nsiofg. 
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1.3. Introduction 

Image interchange among financial institutions can only take place on a wide scale with the incorporation 
of standards. This standard defines the structure which financial institutions shall use to interchange 
images. Image interchange will occur among a wide variety of financial institutions using an array of 
hardware and software, for a number of purposes, some of which are not yet known. The image 
interchange arena will continue to evolve. Although X9 anticipates that future technology will provide 
imaging structures which are acceptable by all image systems used for financial purposes, the current 
environment consists of many different technologies that are not necessarily compatible with one another 
when used to exchange images between financial institutions. 

This standard establishes the architectural structure, protocol, and system design for image interchange 
in this heterogeneous environment It does not attempt to define business practices, rules, and/or 
regulations. The standard does require that financial institutions, and intermediaries, entering into 
exchange of Images will establish formal banking practices agreements that define, for their own 
purposes, acceptable image quality, time frames, liabilities, right of refusal, penalties, etc. Annex C Is 
included for informational purposes to provide a framework for parties entering into image interchange, 
concerning areas that should be addressed by a banking practices agreement. The importance of these 
agreements cannot be overly emphasized. The activity of exchanging a Financial Image Interchange 
which conforms to this standard is based on existing regulations, e.g., Uniform Commercial Code (UCC) 
and the Federal Reserve's Regulation CC . 

Also assumed is every financial institution's commitment to quality images. Quality images require the 
use of checks designed to meet the specifications stated in X9.7-1988. When introducing image related 
products to their customers, financial institutions should clearly explain the requirement to use approved 
check designs and customer liabilities for failure to do so. 

The electronic data interchange (edi) fo rmat provides a structure - to carry financial data , comp ressed 
ihwge dateu Imd d^OTptive^ may be conveyed irVthe 

interchange as binary information. The standard offers the opportunity to request one or more views of all, 
or a portion of one or more, imaged items in an quasi-interactive interchange. As such, the standard 
provides for the application to be operated according to normal transaction processing practices, be 
request driven, or both. 

The Financial Image Interchange structure specified in this document supports the capabilities and 
functions identified above. This standard is primarily intended to enable the interchange of check images 
among financial institutions. For the interchange of check items, the standard specifies that the imaged 
check should contain a "9 1 * in the EPC field and that a banking practices agreement shall exist among 
trading partners. It also specifies the interchange syntax, and the image parameter options (such as 
compression algorithms) which are supported. 

2. Normative references 

The following standards contain provisions which, through reference in this text, constitute provisions of 
this American National Standard. At the time of publication, the editions indicated were valid. All 
referenced documents are subject to revision and In general, parties to agreements based on this 
American National Standard are encouraged to investigate the possibility of applying the most recent 
edition of those documents referenced below. Members of ISO/IEC maintain registers of currently valid 
International Standards. In the US, ANSI is the ISC/IEC member. The ITU Secretariat maintains a list of 
currently valid CCnT/lTU-T Recommendations. The ANSI Secretariat maintains a list of valid ANSI 
Standards. 
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1 . Scope and introduction 

1.1. Scope 

This document defines a standard electronic data interchange (edi 1 ) structure (protocol) that can be used 
to exchange electronic digitized images of financial documents (e.g. checks) among the different financial 
institutions involved in a payment transaction. This standard uses edi to enable the exchange across 
diverse computing platforms. It specifies the MICR identifier to be placed on a document that is eligible to 
be truncated, i.e., the physical item may be retained at the first image system institution, and its image 
may be transmitted to the paying institution in lieu of the actual physical document. It identifies the various 
image parameter options (such as, compression algorithms, spatial scan densities, and levels of gray) 
that this standard supports, and offers the open-ended opportunity for expansion of these as development 
continues in this field. This standard further supports the exchange of imaged items by providing 
mechanisms for conveying financial data structures which are defined external to this standard. Also, it 
defines a query protocol that may be used to request specific imaged items, or to request groups of 
imaged items being held in another institution's image storage facility. Furthermore, this standard 
facilitates end-to-end, self contained, confirmed services by including two levels of acknowledgments: 
syntax checking acknowledgments, and application acceptance or rejection acknowledgments. User 
applications may also utilize the defined security mechanisms which are designed to provide 
authentication, non-repudiation, and data protection services. It is also anticipated that the standardized 
formats will be used beyond the limits of the standard, and will facilitate the interchange of user defined 
data, and non-check items. 

This standard emphasizes that the commercial usage of its technology is dependent upon the 
establishment of formal Banking Practice Agreements between participating institutions. 

For_electronic check exchange, this standard uses references and exampl es from X9.37-1 994. Othe r 

""references and examples are considered be outside the scope of tfiis starTdard; 

NOTE - If X9.37 is not used between institutions for the exchange of Electronic Check Exchange data, then a 
local mapping of the standardized data elements to the non-X9.37 format for electronic check exchange should 
be developed by those users. 

1.2. Purpose 

This standard is intended to improve the payments system by supporting the interchange of digitized 
images of financial documents, specifically checks and similar paper-based instruments; facilitate the 
truncation of the paper at the earliest possible point in the clearing process; and support transmissions 
from a single transaction to many transactions serving banking payment processing applications. 

The standard may also be used in support of deferred paper delivery, interactive interchange, or other 
variations as agreed upon by the exchanging parties. 



To accommodate X12, this standard refrains from using the term "EDI". X12 requires thai if the term ED/ is used, then ell data 
elements, data segments, transaction sets, and functional groups are defined In X1&22 (i.e , the X12 data dictionary.) Since 
many of the data elements and data segment definitions specified in this standard am not defmecfin the X12 data dictionary, the 
term FU or "edi" is used throughout this standard. 
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Work Group 9 would like to offer special thanks to John Driscoll (Bank of America) who was the Work 
Group's first chair. It would also tike to recognize three subgroup chairs: Wayne Doran/Architecture 
(NCR), Tom Hayosh/Compression Techniques and Testing (Unisys) and Helene Kontonis/User 
Requirements (Chase) for their efforts. Finally, the Work Group would like to offer thanks to Dick 
Jesmajian and Yitzhak Ronen (AT&T Bell Laboratories) for their fine efforts as Technical Editors in putting 
together a very complex document. 
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Under ASC X9 procedures, a working group may be established to address specific segments of work 
under the X9 Committee or one of its subcommittees. A working group exists only to develop standard(s) 
or guideline(s) in a specific area and is then disbanded. The individual experts are listed with their 
affiliated organizations. However, this does not imply that the organization has approved the content of 
the standard or guideline. (Note: Per X9 policy, company names of non-member participants are fisted 
only if, at time of publication, the X9 Secretariat received an original signed release permitting such 
company names to appear in print.) 
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Financial Image Interchange Protocol Standard 

Foreword 

At the end of World War II, it became evident that practices for check processing could not adequately 
accommodate the growing volume of financial transactions in an expanding national economy. A method 
to reduce significantly the manual labor associated with the check-clearing system, that would at the 
same time increase the speed with which transaction could be settled, was required. Magnetic Ink 
Character Recognition (MICR) was the method selected to achieve these goals, and that technology, with 
refinements and improvements made during the intervening forty years, permitted the payment system to 
keep pace with the growth of transaction activity which is now over one hundred times larger than it was 
at mid-century. 

As the end of the twentieth century approaches, we are faced with the challenge of improving the check 
processing and clearing process to achieve greater efficiency, to effectively manage costs, and to support 
new financial institution products and services. These demands exceed any foreseeable improvement in 
the present MICR system for handling paper-based transaction records, and once again, leading-edge 
technology is being called upon to provide a means to overcome this hurdle. Digital imaging is expected 
to be the method that will provide this next step in system improvement Once converted to digital image 
form, paper checks need no longer be manually (or mechanically) handled or transported. Thus, both 
cost of processing and time required should Improve substantially. 

Because paper documents, principally checks, are the starting point, it is anticipated that financial 
institutions will handle both digital image and physical paper during a potentially lengthy transition period. 

It is also antiripated that ima^ 

items not presently identified as "checks 0 . For these reasons, this standard has been structured in such a 
way that permits the present MICR system to continue in general use, without limiting expansion of new 
image technology. 

This standard contains 10 annexes. Annexes A and B are normative (integral part of the standard). 
Annexes C, D, E, F, G, H, I, and J are informative (provided for information purposes only). 

Suggestions for improvement of this standard will be welcome. They should be sent to the X9 Secretariat, 
American Bankers Association, 1 120 Connecticut Avenue, NW., Washington, DC 20036. 

This standard was processed and approved for submission to ANSI by the Accredited Standards 
Committee X9 Financial Services. Committee approval of this standard does not necessarily imply that all 
committee members voted for its approval. At the time it approved this standard, the X9 committee had 
the following members: 

Harold G. Deal, Chairman 

Jack Kilhefner.Vice Chairman, Administration 

Cynthia L. Fuller, Associate Director, ABA Standards Division 

Deborah Kate, Assistant Division Manager, ABA Standards Division 

Organization Represented Representative 

Advantis Eisenstaeclt, Ms. Lore 

American Bankers Association Livingston, Ms. Anne 

American Express Company Howard, Ms. Bonnie 

Applied Communications Reed, Ms. Sonia 

Banc One Services Corp Lyons, Mr. William 

Bank of America Breiling, Ms. Gretchen 
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Abstract 

This standard defines an open electronic data interchange (edi) protocol for use by the financial industry in 
the exchange of imaged items and financial data across a heterogeneous computing environment In 
accordance with the user requirements and system overview specified herein, and supplemental Technical 
Reference Guide, this standard specifies an architecture and system design for the end-to-end exchange of 
digitized images of financial documents. The data structures, and data elements, are defined according to 
X12.5 and X12.6 Electronic Data Interchange principles, and syntax, for engaging in electronic financial 
commerce. This standard also supports the ability for users to request views of an imaged item from 
cooperating financial institutions, as well as a means to acknowledge receipt of a Financial (mage 
Interchange at the interchange, or component levels of the interchange. It also provides a means for digitally 
signing transaction sets, and their contents, as well as canceling outstanding query requests and aspects of 
previously sent interchanges. 
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